Personal Catalogue: PHP & MySQL — Chapter 1, Exercise 2
====================================================

TASK
Explain what PDO::ATTR_EMULATE_PREPARES => false actually changes, and
why it matters for this project's own real security.

SOLUTION

By default, PDO's emulated-prepares mode is turned ON (true). In that
mode, when you call $pdo->prepare($sql) and then execute() it with
parameters, PDO does NOT send the raw SQL and the parameters to MySQL
separately. Instead, PDO itself substitutes the parameter values directly
into the SQL string (escaping them along the way) and sends the whole
thing to MySQL as one already-assembled query. MySQL's own prepared
statement machinery is never actually used — PDO is only simulating the
prepare/execute pattern on the client side.

Setting PDO::ATTR_EMULATE_PREPARES => false switches this off. With it
false, PDO sends the SQL template (with its placeholders, e.g. `WHERE
id = ?`) to MySQL first, MySQL compiles that template once, and only
then does PDO send the actual parameter values in a completely separate
step. MySQL's own real prepared-statement protocol keeps the SQL
structure and the data cleanly separated at the protocol level — there
is no string-substitution step for an attacker's input to ever hide
inside.

This matters for security because emulated mode's escape-and-substitute
approach depends on PDO's own escaping logic being flawless for every
possible input, in every possible context, for every version of MySQL's
own escaping rules — a category of bug that has genuinely happened in
real ORMs and drivers in the past, particularly around unusual character
sets. Native prepared statements make the entire class of "malicious
input escapes its quotes and becomes SQL" bug structurally impossible,
because the data is never re-parsed as part of the SQL text in the first
place.

A concrete illustration: with a native prepared statement, sending the
value `' OR '1'='1` as a search term is simply treated as a nine-character
string to search for — MySQL already knows this position is a data value,
not SQL syntax, before that value ever arrives. In emulated mode, that
same string briefly exists as literal text inside an assembled SQL
statement, and its safety depends entirely on PDO's own escaping getting
it right.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains the real mechanical difference (client-side string
substitution vs. a genuine two-step protocol exchange with MySQL),
not just "it's more secure," and gives a concrete example of the
attack class the setting closes off.