SQL injection prevention cheat sheet

SQL injection (SQLi) has been a top-tier web application risk for more than two decades, and it hasn’t gone away. Injection is still ranked among the five most critical risks in the OWASP Top 10, and it was central to some of the highest-profile breaches of the past few years. These included the widespread MOVEit Transfer attacks of 2024 as well as a SQL injection flaw in PostgreSQL (CVE-2025-1094) that enabled a BeyondTrust Remote Support zero-day, with affected entities including the US Treasury Department. 

The vulnerability class itself hasn’t changed. What changes is how much of your codebase, your ORM’s escape hatches, and your API surface you’ve actually checked.

What is SQL injection prevention?

SQL injection prevention is the set of secure coding practices that stop untrusted input from altering the structure of a SQL query. The core technique is the use of parameterized queries (prepared statements), which separate SQL code from user-supplied data at the database driver level so that input can never be interpreted as part of the query itself. Input validation, least-privilege database access, and continuous DAST scanning all support that core defense.

Types of SQL injection attacks

SQL injection vulnerabilities are a wide class of security flaws that let an attacker supply database commands through application input and have them executed by the database server. The main variants differ in where and how the payload surfaces:

• In-band (“regular”) SQL injection: The attacker injects malicious SQL directly into an inline query and sees the result in the application’s response. This includes both error-based and union-based SQL injection.
• Blind SQL injection: The attacker infers data using Boolean logic or time-based techniques when no error messages or query output are shown, typically by observing page behavior, response content, or response timing.
• Out-of-band SQL injection: The attacker extracts data through a side channel, such as a DNS or HTTP request triggered by the database server, when no direct response is available.
• Second-order SQL injection: A malicious payload is stored safely at first and only triggers the injection later, when the application reuses that stored value in a different query. It’s often missed during testing because nothing happens at the point of input.

For a wide set of example payloads by injection type, see the Invicti SQL injection cheat sheet.

Best practices for preventing SQL injection vulnerabilities

Avoid building SQL queries with string concatenation

Directly including user data in a query string is inherently unsafe. Concatenating user input with SQL code mixes application data and application logic in the same string, leaving room for an attacker to control what the database executes. An insecure concatenated query in PHP might look like this:

$query = "SELECT * FROM users WHERE userid = " . $_GET['userid'];

If an attacker can control the value of the userid parameter, the application is vulnerable to SQL injection, regardless of what framework or language sits around this line of code.

Build queries safely with parameterized queries or prepared statements

The number one rule for preventing SQL injection is: never insert user input directly into SQL code. Whether you’re working with MySQL, PostgreSQL, Oracle, or Microsoft SQL Server, use parameterized queries or prepared statements everywhere user input reaches a database call. The database engine compiles the query structure before binding the input values, so special characters in the input can’t alter the query’s logic.

Java example

Using the JDBC PreparedStatement API, the ? placeholder holds the position of the value and setInt binds it after the query is already compiled:

// Make sure conn is a valid open Connection, and handle exceptions properly in production code
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE userid = ?");
stmt.setInt(1, userId); // userId holds the user-supplied value
ResultSet rs = stmt.executeQuery();

PHP (PDO) example

PHP Data Objects (PDO) uses the same idea with named placeholders, which can make longer queries easier to read than positional ones:

// Remember to set PDO::ATTR_ERRMODE to handle errors properly
$stmt = $pdo->prepare("SELECT * FROM users WHERE userid = :userid");
$stmt->execute(['userid' => $userId]); // $userId holds the user-supplied value

Python (psycopg2) example

The %s placeholder here is a driver-level parameter marker, not Python string formatting, so it’s safe even though it looks similar:

# PostgreSQL with psycopg2 – parameterized query
cursor.execute("SELECT * FROM users WHERE userid = %s", (user_id,))

Node.js (mysql2) example

The same pattern holds for asynchronous drivers: the placeholder and the bound value travel to the database separately, regardless of how the surrounding code is structured:

// MySQL with mysql2 – parameterized query
const [rows] = await conn.execute(
    'SELECT * FROM users WHERE userid = ?',
    [userId] // userId is bound as a parameter, not concatenated
);

Validate input to reduce risk and enforce intent

Parameterization is what stops injection, but input validation still matters for resilience: it catches malformed data early and shrinks the attack surface before a request ever reaches the query layer. Use allowlists for fields with a known, closed set of valid values, and check that integers are really integers and strings match expected patterns. 

Here’s a validation example for PHP:

if (!filter_var($userid, FILTER_VALIDATE_INT)) {
    throw new Exception("Invalid userid");
}

This rules out malicious string values in the userid parameter, but note that it validates format only – it still doesn’t replace the need for a parameterized query.

Handle stored procedures carefully

Stored procedures can improve security but only when they use parameterized inputs and avoid dynamic SQL internally. A procedure that builds a query by concatenating its own input parameters and then runs it with EXEC or sp_executesql reintroduces the same injection risk you were trying to remove. 

The safe pattern is a fixed query structure with parameterized inputs, as in this Oracle example:

CREATE PROCEDURE GetUser(p_userid IN NUMBER) AS
BEGIN
    SELECT * FROM users WHERE userid = p_userid;
END;

Your application code then calls this procedure with a bound parameter, the same way it would call a prepared statement, rather than building the call by concatenating input into a dynamic SQL string.

Use ORMs carefully

Modern object-relational mapping (ORM) frameworks such as Hibernate, Django ORM, and SQLAlchemy parameterize queries automatically when you use their standard query APIs. This is ostensibly more secure by default, but risk can still show up if developers reach for the ORM’s raw-query escape hatch to handle a complex query, and build that raw string with concatenation instead of parameters. 

Safe and unsafe examples for Hibernate:

// Safe: HQL with a named parameter
Query query = session.createQuery("FROM User WHERE id = :userId");
query.setParameter("userId", userId);

// Unsafe: string concatenation in HQL
Query unsafeQuery = session.createQuery("FROM User WHERE id = " + userId);

The same pattern applies in Django ORM:

# Django ORM – safe by default
User.objects.filter(id=user_id)

# Unsafe: raw() built with an f-string
User.objects.raw(f"SELECT * FROM auth_user WHERE id = {user_id}")

# Safe: raw() but with a bound parameter
User.objects.raw("SELECT * FROM auth_user WHERE id = %s", [user_id])

Treat any raw SQL inside an ORM-based codebase with the same scrutiny you’d apply to an application with no ORM at all.

Apply the same discipline to APIs

REST and GraphQL endpoints are exposed to the same injection risk as traditional web forms, and the attack surface is often larger and less visible: path parameters, query strings, JSON request bodies, and GraphQL field arguments can all end up inside a database query. A GraphQL resolver that interpolates an argument into a query string is just as vulnerable as an unparameterized SQL statement anywhere else:

// Unsafe GraphQL resolver
user: (_, { id }) => db.query('SELECT * FROM users WHERE id = ' + id);

// Safe GraphQL resolver (parameterized)
user: (_, { id }) => db.query('SELECT * FROM users WHERE id = $1', [id]);

Automated API security testing should cover these input paths specifically, since they’re easy to miss in a manual review focused on form fields.

Handle errors securely

Avoid exposing detailed error messages that reveal table names, column names, or query structure. Return generic error messages to users and log the details server-side. Standardizing your error handling this way can also make some timing-based attacks harder to pull off.

Monitor and log queries

Monitoring helps you catch unusual query patterns, such as repeated Boolean conditions or time-based delays, that point to blind SQL injection attempts. Watch application and database logs for unexpected SQL commands and failed authentication attempts. As a general precaution, sensitive data should never be written to logs in the first place.

Keep your tech stack updated

Update your application components, ORMs, database drivers, the DBMS itself, and the underlying operating system on a regular schedule. This applies equally to open-source and commercial platforms, from MySQL and PostgreSQL to Oracle and Microsoft SQL Server. Staying up-to-date limits your exposure to newly disclosed vulnerabilities, including in the database engine itself: the PostgreSQL flaw behind the BeyondTrust breach is a reminder that the database layer, not just application code, needs to stay patched.

Apply the principle of least privilege

This won’t stop an attack from happening, but your application should connect to the database using a low-privilege account limited to the tables and columns it actually needs. If an attacker does find and exploit a SQL injection flaw somewhere, least privilege limits what they can do with it. The database server itself should also run with only the permissions and features it needs.

Don’t rely on a WAF as your primary SQLi defense

A web application firewall can catch many SQL injection attempts through signature matching, but attackers can and do bypass WAF rules using encoding tricks, comment sequences, and unusual syntax that signature-based detection doesn’t anticipate. Treat parameterized queries as the primary control and a WAF as a secondary layer of defense in depth, not the other way around.

Follow secure coding practices, and test for what slips through

Every one of the practices above reduces risk, but the only way to know your application is actually safe is to test it, and test it again at every stage of development. Static application security testing (SAST) can flag risky patterns, such as string concatenation in a query or an unparameterized ORM raw call, while code is still being written. Dynamic application security testing (DAST) is what confirms whether the running application is actually exploitable, including SQL injection classes that never surface in source code review.

The Invicti Platform tests for all major SQL injection types, including in-band, Boolean-based blind, time-based blind, and out-of-band injection. For blind and out-of-band cases, where no evidence of the injection appears in the HTTP response, Invicti OOB confirms exploitation through an external callback, so a finding comes with proof rather than a guess. Combined with proof-based scanning, that means confirmed SQL injection findings arrive with a proof of exploit attached, so your team can prioritize what’s real instead of triaging every possible alert by hand – and with DAST-SAST correlation, many SQLi findings are automatically deduplicated.

Final thoughts

Preventing SQL injection takes more than a single fix. It’s the combination of parameterized queries, careful ORM and API handling, input validation, least privilege, and continuous testing that keeps this decades-old vulnerability class out of your production environment. Pair the practices in this cheat sheet with a DAST-first approach to application security, and you’ll catch what manual review and static analysis alone tend to miss. Request a demo of the Invicti Platform to see this at work in your app and API environments.