Home / Blog / SQL Injection Prevention: A Language-by-Language Guide (PHP, Python, Node.js, .NET)
Software Development

SQL Injection Prevention: A Language-by-Language Guide (PHP, Python, Node.js, .NET)

AJAjish Stephen August 8, 2026 8 min read
SQL Injection Prevention: A Language-by-Language Guide (PHP, Python, Node.js, .NET)

SQL injection has been on the OWASP Top 10 for over two decades, and it still shows up in real codebases in 2026 — not because developers don't know it exists, but because the vulnerable pattern is easy to write by accident under deadline pressure. The fix is the same idea in every language: never build a query by concatenating untrusted input into a string. Here's what that looks like, and what the safe version looks like, across four common stacks.

Why it happens

A SQL query is just a string until the database parses it. If user input becomes part of that string before parsing, the database can't distinguish "data" from "instructions" — an attacker who controls part of the string can inject their own SQL logic. Parameterized queries fix this at the protocol level: the query structure and the data are sent to the database separately, so injected SQL syntax in the data is always treated as literal data, never as part of the query.

PHP

// ✗ Vulnerable — PDO with string concatenation
$stmt= $pdo->query("SELECT * FROM users WHERE email = '".$email."'");

// ✓ Safe — PDO prepared statement
$stmt= $pdo->prepare('SELECT * FROM users WHERE email = ?');
$stmt->execute([$email]);

Python

# ✗ Vulnerable — f-string interpolation
cursor.execute(f"SELECT * FROM users WHERE email = '{email}'")

# ✓ Safe — parameterized (DB-API style)
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

Node.js

// ✗ Vulnerable — template literal interpolation
connection.query(`SELECT * FROM users WHERE email = '${email}'`);

// ✓ Safe — parameterized (mysql2 / pg style)
connection.query('SELECT * FROM users WHERE email = ?', [email]);

.NET

// ✗ Vulnerable — string interpolation
varcmd= newSqlCommand($"SELECT * FROM Users WHERE Email = '{email}'", connection);

// ✓ Safe — parameterized
varcmd= newSqlCommand("SELECT * FROM Users WHERE Email = @Email", connection);
cmd.Parameters.AddWithValue("@Email", email);

The pattern that connects all of these

The query structure is a fixed string with placeholders (?, %s, or a named parameter)
User input is passed separately, never concatenated or interpolated into the string
Every raw-query escape hatch (raw(), extra(), db.query with a built string) reintroduces the same risk — treat these as red flags in code review regardless of language

Auditing an existing codebase for exactly this pattern, or building something new that needs to be safe from the start? This is part of what I cover in DevOps services and application security review engagements.

Common questions

Are ORMs completely immune to SQL injection?
No ORM is immune once you drop into its raw-query escape hatch and build that raw query with unparameterized string concatenation. ORMs are safe for their standard query-building methods, but every ORM has a raw SQL option with the same risk.
Is input validation enough to prevent SQL injection?
Validation helps but is not sufficient on its own. Parameterized queries prevent injection structurally, regardless of what the input contains — that must always be the primary defense.
Does using stored procedures automatically prevent SQL injection?
Only if the stored procedure itself uses parameters correctly. A stored procedure that concatenates a parameter into a dynamic SQL string internally is just as vulnerable.
How can I check if my existing codebase has SQL injection vulnerabilities?
Search the codebase for raw query functions combined with string concatenation or string formatting. Static analysis tools for your specific language and framework can also flag these patterns automatically.
Not sure if your codebase has this vulnerability?
I audit real applications across PHP, Python, Node.js, and .NET for exactly these patterns.
Explore DevOps Services →
© Copyright 2024 Ajish Stephen