PDO in PHP: Does It 100% Protect Against SQL Injections?

Introduction: Myths and Reality of PDO

If you write PHP and have ever Googled "how to protect against SQL injections," you've likely heard the mantra: "Use PDO and prepared statements — and you'll be safe". This is the gold standard, the foundation of every PHP security tutorial. But is it really true? Is it enough to just write $stmt = $pdo->prepare('SELECT * FROM users WHERE id = ?') and forget about the problem?

The question "Are PDO prepared statements sufficient to prevent SQL injection?" has garnered thousands of views on Stack Overflow for a reason. The answer, as it turns out, is not so straightforward. In this article, we'll dive under the hood of PDO, break down how prepared statements actually work, and find out in which cases even PDO can let you down.

This isn't boring theory. We'll look at real examples, query emulation, encoding nuances, and provide specific action items to make your code truly secure.

How Prepared Statements Work: Magic or Math?

First, let's recall what an SQL injection is. It's when an attacker passes data into a query that gets interpreted as part of the SQL code. Classic example: ' OR 1=1 --.

Prepared statements solve this problem radically. They separate query logic from data. It looks like this:

<?php\n$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');\n$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email AND status = :status');\n$stmt->execute([':email' => $_GET['email'], ':status' => 'active']);\n?>\n

Here's what happens under the hood:

\n
1. Prepare: The driver sends the database server a query "skeleton": SELECT * FROM users WHERE email = ? AND status = ?. The server parses this skeleton, optimizes it, and remembers the execution plan. The placeholders for data are left empty.
\n
2. Execute: Now you send only the actual values. The server inserts them into the already prepared plan, but it does so in a special way — it knows these are data, not code. Therefore, any attempt to "close a quote" or add an SQL command simply becomes part of a string literal.
\n

Sounds perfect. But there's a catch.

The Pitfall: Emulated Prepared Statements

The main surprise revealed by that Stack Overflow question is: PDO by default does not always use "real" prepared statements.

The issue is that not all databases support this feature at the protocol level. And some drivers (e.g., for SQLite or older MySQL versions) work through emulation. What does that mean?

When emulation is enabled, PDO substitutes values into the SQL query on the client side (in PHP) and then sends the already complete query to the server. It does this by escaping special characters using PDO::quote().

And this is where problems start. Emulation is essentially the same string substitution, just performed by the library. And if you've set the connection encoding incorrectly, this mechanism can be broken.

Example: Attack via Different Encodings

A classic attack using incorrect encoding looks like this. Suppose you establish a MySQL connection with the GBK encoding (a Chinese encoding), and the query is emulated. The \\ (backslash) character in GBK can be part of a multi-byte character.

An attacker sends the string: %BF%27. In GBK encoding, the sequence %BF%5C forms a single character, while %27 is just a quote. The emulator sees the quote and escapes it, turning %27 into %5C%27 (i.e., \\'). But because