Preventing SQL injection with parameterised queries

Goal

Make it impossible for user-controlled text to change the structure of a SQL statement.

Prerequisites

A database driver or query builder that supports bound parameters (all mainstream ones do).

Steps

1. Write statements with placeholders and pass values separately: WHERE id = :id with a parameter dictionary, never an f-string or % formatting with user data.
2. Use the ORM or query builder for the common cases; when hand-writing SQL, keep parameters for every value including those from your own configuration.
3. Where table or column names must vary (sorting by a user-chosen column), map the user's choice to a fixed allow-list of identifiers in code.
4. Apply the least privilege to the database role the application uses: no DDL, no access to unrelated schemas.
5. Review every occurrence of string building near SQL in code review and with a linter rule.

Expected result

Inputs such as ' OR 1=1 -- are stored or compared as literal text; the database role cannot do damage even if a statement were injected.

Limits and test basis

Parameters protect values, not identifiers or LIMIT expressions in some drivers; those need allow-lists. Stored procedures and dynamic SQL inside the database can reintroduce the problem. The guidance follows the cited cheat sheet.