Module 4 · SQL Injection in 2026

Last updated: May 1, 2026

SQL injection has been on every Top 10 list since OWASP started publishing one in 2003. It’s still on the list in 2026. The 20-year-old basic patterns are largely mitigated in modern frameworks, but the bug persists in three places: legacy code bases with hand-constructed queries, unsafe usage of ORMs that developers trust blindly, and dynamic query building in reporting or admin features where the usual safety rails get bypassed.

A successful SQLi in 2026 typically means one of these: enterprise intranet app on Oracle or SQL Server with stored-procedure bugs, a modern API with a developer-built “flexible filters” feature, or a Python app doing raw cursor.execute(f"SELECT * FROM users WHERE id={user_id}") because they forgot parameterization. This module covers the techniques to find all three.

How SQL injection works

The server has a SQL query template. User input is meant to fill in part of the query, but because the input isn’t properly separated from the query structure, the input can change the structure itself.

# Vulnerable (Python):
query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"

# Benign input: username='alice', password='secret'
# Resulting query:
SELECT * FROM users WHERE username = 'alice' AND password = 'secret'

# Malicious input: username="admin' --", password="anything"
# Resulting query:
SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'
# The -- comments out the rest; admin logs in without a valid password.

The root cause: user input mixed with query structure via string concatenation. The fix: always use parameterized queries — the query template is fixed, and parameters are sent separately and bound to placeholders by the database driver, not the application.

# Safe (Python):
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password)
)
# Even if username is "admin' --", the driver treats it as a literal string.