SQL injection and parameterisation

Injection has exactly one mechanism, and it is the same in SQL, a shell, XML, a template engine and a browser: you build a command string by concatenating data into it, then hand that string to an interpreter. The interpreter has no way to know which part is your command and which is somebody else's data — it sees one string.

Which means the right review question is not "is this input validated" but "does this data ever become syntax". Two different questions, and the second has only one safe answer.

Parameterisation solves it in a fundamentally different way from escaping: it does not modify the data. It sends the statement and the data down two separate channels in the protocol, so the interpreter knows the boundary before it ever sees the data. There is no string to break out of.

Why escaping is the wrong answer even though it "works":

• It is correct for one database, one charset, one SQL mode. Change any of the three and it is wrong.
• It requires you to remember it everywhere. With parameterisation, the place you forget is the place that stops working — the error shows up at development time rather than waiting silently.
• It cannot handle types: an escaped int is still a string, and 1 OR 1=1 contains no quote to escape.

That last point surprises people: injection does not need a quote. If the parameter lands somewhere unquoted — WHERE id = 1 — then escaping quotes buys you precisely nothing.