Overview
The definitive defense against SQL injection is the parameterized query (prepared statement), which structurally separates query code from data. This lesson explains how parameterization works and why it reliably prevents injection.
Learning objectives
- Define parameterized queries / prepared statements.
- Explain why they prevent injection by design.
- Contrast them with string concatenation.
Core concept
A parameterized query defines the query's structure with placeholders for values, then supplies the values separately as parameters. The database treats the parameters strictly as data — never as part of the query's code — so user input cannot alter the statement's structure. This enforces the code/data boundary by design, which is exactly what injection violates.
Most languages and frameworks provide prepared statements or safe query builders/ORMs that parameterize automatically.
How it works
With a parameterized query, the application sends the query template (with placeholders) and the parameter values as distinct components. The database parses the template first, fixing the statement's structure, and then binds the values into the placeholders as pure data. Because the structure is already determined before the values are attached, no value — however crafted — can change what the query does. This is fundamentally more robust than trying to sanitize input, because it removes the possibility of injection rather than attempting to filter it out.
Practical example
Instead of concatenating input, a safe login uses a template like select * from users where user = ? and pass = ? and passes the username and password as separate parameters. Even if the input contains SQL syntax, the database uses it only as a literal value to compare — it cannot become part of the query logic. The same login that was injectable via concatenation becomes safe purely by switching to parameters, with no input filtering required.
Cybersecurity relevance
Parameterized queries are the recommended, industry-standard defense against SQL injection precisely because they eliminate the root cause. Where developers must build dynamic queries, they should still use parameters for all values (and allowlist any structural elements like column names that cannot be parameterized). ORMs and query builders typically parameterize by default — a strong reason to use them safely rather than hand-building query strings. Testers confirm that inputs reaching queries are parameterized; the presence of concatenation is a red flag.
Common mistakes
- Concatenating "just this one value" into a query instead of parameterizing consistently.
- Assuming an ORM is automatically safe even when using its raw-query/string features unsafely.
- Trying to parameterize structural parts (table/column names) that require allowlisting instead.
Key takeaways
- A parameterized query fixes the query structure with placeholders and supplies values separately as data, so input cannot alter the statement.
- It prevents injection by design (enforcing the code/data boundary), which is more reliable than input filtering.
- Use prepared statements / safe query builders/ORMs for all values; allowlist any structural elements that cannot be parameterized — the standard SQLi defense.
Check your understanding
- Why can a value passed as a query parameter never change the query's structure?
- Why are parameterized queries more reliable than filtering dangerous characters from input?