How to Prevent SQL Injection: A Developer’s Checklist

1 Parameterised queries (prepared statements): non-negotiable

This is the primary fix. A parameterised query separates the SQL structure from the data. The database compiles the query structure first, then binds user-supplied values as parameters. User input cannot change the query structure because it is never interpreted as SQL code.

Python with SQLite:

cursor.execute(
  'SELECT * FROM users WHERE username = ? AND password = ?',
  (username, password)
)

Java with JDBC:

PreparedStatement stmt = conn.prepareStatement(
  "SELECT * FROM users WHERE username = ? AND password = ?"
);
stmt.setString(1, username);
stmt.setString(2, password);

PHP with PDO:

$stmt = $pdo->prepare(
  'SELECT * FROM users WHERE username = :username AND password = :password'
);
$stmt->execute(['username' => $username, 'password' => $password]);

2 Stored procedures with fixed logic

A stored procedure is a predefined SQL routine in the database. If the procedure accepts parameters and does not concatenate them into dynamic SQL internally, it provides the same structural separation as a parameterised query.

Stored procedures are not automatically safe. A stored procedure that builds dynamic SQL internally using EXEC or sp_executesql with concatenated input is just as vulnerable as inline string building. Stored procedure usage must be combined with parameterisation of the inputs.

3 Input validation: reduce the attack surface

Validate inputs against what you expect. A field that should accept a user ID should only accept integers. A field that should accept a username should only accept alphanumeric characters within a defined length. Reject anything that does not match the expected pattern before it reaches the database layer.

Input validation is a reduction of attack surface, not a prevention of SQL injection on its own. Attackers who understand encoding, multi-byte characters, and application logic can bypass client-side and many server-side validation patterns. It slows attackers down. It does not stop them without parameterised queries underneath.

4 Least-privilege database accounts

The database account your application uses to connect should have only the permissions required for its function. A read-only application needs only SELECT. An application that writes orders needs INSERT on the orders table, nothing else.

An application running as a database administrator account multiplies the damage of any SQL injection vulnerability. The attacker can read, write, delete, and in many database configurations execute system commands. Least privilege limits what an attacker can do even when injection succeeds.

• Revoke DROP, TRUNCATE, and ALTER from application accounts.
• Use separate accounts for read and write operations where practical.
• Never use the database root or sa account in application connection strings.

5 Web Application Firewall (WAF): detection, not substitution

A WAF inspects incoming HTTP requests and blocks or flags patterns that match known SQL injection signatures. It adds a layer of detection that can catch automated scanning and some manual injection attempts. It is not a substitute for parameterised queries.

Skilled attackers encode payloads, use time-based blind injection, or chain application logic in ways that WAF signature rules do not detect. If your application is vulnerable, a WAF provides a speed bump. It does not fix the code.

6 Error handling: do not expose database structure

Verbose error messages that include SQL syntax, table names, column names, or stack traces give attackers the information they need to refine their injection attempts. Error-based SQL injection specifically exploits this by causing deliberate errors to extract schema information.

In production, show generic error messages to users and log detailed errors to a secure, access-controlled system. Never expose raw database errors in HTTP responses.

7 Test your own code before someone else does

Run SQL injection tests on your application before it reaches production. OWASP ZAP (free, open-source) and Burp Suite Community Edition (free) both automate SQLi testing against running applications. sqlmap is the most widely used command-line SQL injection testing tool.

Manual testing with the input patterns in the table above on every user-input field in your application takes two to three hours. Automated scanning with ZAP takes 15 minutes to set up. Both are faster and cheaper than discovering a vulnerability in production.