SQL injection attacks exploit a simple design flaw: the application treats user-supplied text as part of the SQL instruction set rather than as data. Once you understand this, the fix becomes obvious — and the reason that naive string sanitisation does not fully solve the problem becomes clear too.
The Core Problem: Strings Are Instructions
When an application builds a SQL query by concatenating user input, it hands the database a string and asks it to interpret that string as a command. The database has no way to distinguish between the parts the developer intended and the parts the user inserted.
Consider a login check where the email and password fields are concatenated directly into the query. If a user submits anything' OR '1'='1 as the password, the resulting SQL condition evaluates as always true. The query returns all rows, and the application logs in as the first user returned — often the admin account. No brute force, no password cracking. Just string manipulation.
Why Escaping Characters Is Not Enough
The naive fix is to escape or remove dangerous characters — single quotes, semicolons, comment sequences (--). This has two fundamental problems.
Encoding bypass: A single quote can be submitted in multiple encoded forms: %27 (URL encoding), ' (HTML entity), or Unicode variants. Depending on how the application decodes inputs, a blacklist that catches one form may miss another.
Context dependency: A character that is dangerous in one SQL context is harmless in another. Escaping based on a global blacklist will either over-escape (breaking legitimate inputs) or under-escape (missing attack vectors in numeric fields, which do not need quote characters at all).
Sanitisation is a defensive layer against known attack patterns. Parameterized queries prevent the attack by design, regardless of what the user submits.
How Parameterized Queries Work
A parameterized query sends the SQL structure and the data values to the database separately. The SQL structure is sent first and compiled into a query plan. The data values are sent after — bound to placeholders — and are never interpreted as SQL syntax.
The database receives the statement with ? placeholders, compiles it, and creates an execution plan. When the application provides the actual values, those values fill the placeholders as literal data. The database does not re-parse them as SQL. No matter what characters the user submits, they are treated as data. The malicious input that would have broken a concatenated query simply fails to match any stored password — as it should.
Named vs Positional Parameters
Different database drivers use different placeholder syntax. Positional parameters use ? and are filled in order. Named parameters use :name syntax and are matched by name, which is more readable in complex queries with many parameters. Named parameters also prevent errors where adding or removing a parameter from the middle of a query shifts the binding positions of all subsequent ones.
Stored Procedures Are Not a Magic Fix
Stored procedures are often cited as a defence against SQL injection. They can be, but only if they use parameterized queries internally. A stored procedure that concatenates its input parameters into a dynamic SQL string and executes it is just as vulnerable as inline concatenated SQL. The vulnerability is in the concatenation, not in where the SQL lives.
Where ORMs Reintroduce the Vulnerability
Most modern ORMs parameterize queries automatically when you use their standard query-building methods, which is a large part of why ORM-based applications tend to have fewer injection vulnerabilities than hand-written SQL. Nearly every ORM also provides a raw or native query method for cases the query builder cannot express — and that escape hatch carries exactly the same risk as raw SQL if a developer concatenates user input into it directly.
The vulnerability is easy to introduce accidentally, since the raw method often looks and feels like a normal part of the ORM's API rather than a clearly marked danger zone. A code reviewer scanning for "raw SQL" in a codebase built on an ORM needs to specifically check every use of the raw or native escape hatch, not just files that look like traditional SQL.
Vulnerable and Safe Versions of the Same Query
Vulnerable: building a query string by directly inserting a variable — "SELECT * FROM users WHERE email = '" . $email . "'" — where $email comes from user input. If $email contains a single quote followed by SQL syntax, the query's structure changes entirely.
Safe: the same lookup using a parameterized query — "SELECT * FROM users WHERE email = ?" with $email passed separately as a bound parameter, never concatenated into the string. The database driver keeps the query structure and the data completely separate at the protocol level, so no value passed as a parameter can ever alter the query's logic, regardless of what characters it contains.
Frequently Asked Questions
Is there ever a legitimate reason to build SQL through string concatenation?
Rarely, and almost never involving untrusted input — dynamically building table or column names (which cannot be parameterized the same way as values) is one of the few cases, and it needs a strict allowlist of valid names rather than direct user input.
Do NoSQL databases need the same kind of protection?
Yes, in a different form — NoSQL databases have their own injection patterns, usually involving operator injection in query objects rather than string concatenation, but the underlying principle of separating user input from query logic still applies.
Can a parameterized query still be vulnerable to any kind of attack?
Parameterized queries close the injection vulnerability specifically, but they do not address authorization — a correctly parameterized query that queries the wrong table or lacks a permission check can still expose data it should not, for a completely different reason than injection.
Why do named parameters matter compared to positional ones?
Named parameters (:email rather than a plain ?) reduce a specific class of bug where the order of bound values in code does not match the order of placeholders in the query — a mismatch that is easy to introduce during refactoring and does not always cause an obvious error.
Does an ORM eliminate the need to understand SQL at all?
No — understanding what the ORM generates underneath, particularly for complex queries or performance-sensitive code, remains valuable, and knowing when the ORM's raw escape hatch is in use is exactly the knowledge that prevents this vulnerability from slipping in unnoticed.
Format and inspect your own SQL with the SQL formatter.
Every modern database library supports parameterized queries — PHP PDO, Python sqlite3, Java JDBC, Laravel query builder. Writing raw SQL with concatenation when a parameterized alternative is available is never justified. Use the SQL Formatter to inspect and clean SQL during development.