SQL Injection is a class of application security vulnerabilities where an attacker can manipulate backend SQL queries by sending specially crafted input. The core issue is unsafe construction of SQL statements—e.g., concatenating user input into query strings—rather than using parameterized queries.

A typical impact is unauthorized data access (e.g., bypassing authentication or reading sensitive records), data modification, and in some cases service disruption. OWASP describes SQL Injection as one of the most common and severe web application risks, largely mitigated by correct use of parameterization and input handling practices.

Key idea: the attacker’s goal is to change the structure or logic of the SQL statement (not just the data). Common patterns include bypassing login checks (e.g., turning a boolean condition into one that is always true) or extracting data via techniques such as UNION-based queries.

What SQL Injection looks like (conceptually)

If an application builds a query like:

SELECT * FROM users WHERE username = '<user>' AND password = '<pass>'

and <user> is taken directly from an HTTP request, then a malicious <user> might be crafted so the resulting SQL WHERE clause no longer enforces the intended constraints. This is why prepared statements and bound parameters are central defenses: they separate query structure from data.

How to prevent it (the practical minimum)

The most reliable prevention is:

1. Use parameterized queries (a.k.a. prepared statements / bound parameters).
2. Avoid concatenating raw input into SQL.
3. Apply least-privilege database accounts so even successful injection has limited reach.

OWASP’s SQL Injection guidance emphasizes parameterized queries as the primary mitigation technique. Additionally, storing database credentials with minimal privileges reduces the damage potential if a bug still exists.

[CalloutBlock]{type="tip" title="Pro Tip" content="If you ever see SQL built via string concatenation with user input, treat it as a security bug until proven otherwise. Replace it with placeholders (e.g., ? or $1) using your language’s database library."}

[CalloutBlock]{type="warning" title="Warning" content="Escaping quotes is not a complete defense. Correct parameterization prevents the attacker from changing SQL syntax/structure, which escaping may not guarantee in all cases."}

Example patterns: unsafe vs safe

Below is a simplified illustration using common placeholder styles.

Unsafe (conceptual)

A common anti-pattern is building SQL text with string concatenation and then executing it. The attacker’s input can then change the SQL’s meaning.

Safe (parameterized)

Use a query template and bind values. The driver sends the query and parameters separately, so the database parses the SQL structure without treating user data as executable code.

[CodeTabsBlock]

• tab: "JavaScript" lang: "javascript" code: | // Unsafe (conceptual): string concatenation with user input // const sql = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"; // // Safe: parameterized query (example with pg) const sql = "SELECT * FROM users WHERE username=$1 AND password=$2"; const result = await pool.query(sql, [username, password]);
• tab: "Python" lang: "python" code: |

  Unsafe (conceptual): f-string or concatenation

  sql = f"SELECT * FROM users WHERE username='{username}'"

  Safe: parameterized query

  sql = "SELECT * FROM users WHERE username=%s AND password=%s" cursor.execute(sql, (username, password))