Home / Knowledge hub / Parameterised queries
Knowledge hub
Parameterised queries
Sending the query and the data separately so input can never become code.
What it means
A parameterised query, also called a prepared statement, sends the database the SQL text and the values in two separate pieces. The text contains placeholders, such as a question mark, and the values fill those slots when the query runs.
Because the database already knows the shape of the statement, it treats each value only as data. Nothing the user types can change what the query does. A name like Robert'); DROP TABLE users;-- is stored as a strange name, not run as a command.
Why it matters
It is the main defence against SQL injection. OWASP describes it as the first and strongest option, because it does not depend on a developer remembering to clean each input. The structure of the query cannot be altered by the data.
The business value is simple: one coding habit removes a whole class of breach. It costs almost nothing to adopt in new code, and finding and fixing the old string-built queries is a far smaller job than responding to a database leak.
How it shows up
Every mainstream language and database driver supports it. You write the query with placeholders and pass values separately. Object-relational mappers do this for you when you use their normal methods, but many also offer a raw query function, which is where problems come back.
Look for the gaps. Placeholders cover values, not table names, column names or sort direction, so those need an allowlist. String concatenation "just for this one report" is the usual lapse. Stored procedures that build SQL inside from their arguments can be injectable as well. Search the code for queries built with string joins.
Questions people ask
Parameterised queries, answered
Are parameterised queries the same as prepared statements?
In practice, yes. A prepared statement is the database feature, and parameterised query describes how you use it from code. People use the two terms interchangeably.
What matters is that values are never joined into the SQL string.
Is escaping input as good?
No. Escaping tries to neutralise dangerous characters, and it is easy to get wrong, or to apply in the wrong place. OWASP lists it as a last resort.
Parameterisation removes the need to guess which characters are dangerous.
Do they protect against every injection?
Only against injection into values of a database query. They do nothing for command injection, cross-site scripting or injection into other languages.
Each destination needs its own safe handling, so parameterised queries are one control among several.
Can I parameterise a table or column name?
Usually not. Placeholders stand in for values only. For names, choose from a fixed list in your code and reject anything else.
The same goes for sort order and similar options.
Do ORMs make this automatic?
Mostly, for normal queries, which is a real help. But raw-query helpers, string-built filters and dynamic ordering can still introduce injection if input reaches them unsafely.
Review those places in particular, since that is where the old habit returns.
Sources
Where this comes from
Related
Terms that sit next to this one
SQL injection
Input a database ends up running as part of a query.
Blind SQL injection
Injection where no data comes back, so answers are read from timing or behaviour.
Injection
Input that ends up running as a command instead of being read as text.
Input validation
Checking that what arrives is the shape and range you expected.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
Is every query built this way?
In white-box mode we read your code while testing the running app, so a string-built query can be tied to the request that exploited it and to the file and line. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.