SQL Injection

What it is

CWE-89 occurs when an application constructs SQL queries by concatenating user input rather than using parameterized queries or prepared statements. An attacker who controls part of the query can modify its meaning: read arbitrary data, modify data, run administrative commands, or in the worst case execute arbitrary code via DBMS-specific features.

Why it matters

SQL injection has been in the CWE Top 25 every year it has been published. Despite three decades of disclosure, parameterized-query adoption is still incomplete, especially in legacy code, dynamically-built filter expressions, and ORM escape hatches. A single SQL injection in a customer database is sufficient for mass credential exfiltration, ransomware staging, or breach disclosure under HIPAA, PCI-DSS, GDPR, and SOX.

Common patterns

• •String concatenation: 'SELECT * FROM users WHERE id = ' + req.params.id
• •f-string or template-string queries in Python or Node that interpolate user input.
• •Dynamic WHERE-clause construction for filter UIs without proper parameter binding.
• •ORM .raw() / .query() / .execute() calls that bypass the ORM's own parameterization.
• •Stored procedures that use EXEC or sp_executesql on dynamically-built strings.

Languages affected

Example

def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query).fetchone()

def get_user(user_id):
    query = "SELECT * FROM users WHERE id = %s"
    return db.execute(query, (user_id,)).fetchone()

Where this fits in OWASP Top 10

Compliance framework mapping

Related CWEs