flawopen.com/SQL Injection/Is escaping enough?
No — not reliably. Escaping is a mitigation applied after the fact; parameterized queries avoid the problem structurally. Escaping has a real, documented history of being bypassed.
Certain multi-byte character-set configurations have historically allowed an attacker to construct a byte sequence that an escaping function doesn't recognize as a quote, but the database driver still interprets as one — a class of bypass that has affected multiple languages' escaping functions over the years, not a hypothetical.
Escaping has to be applied correctly at every single point user input reaches a query. Parameterization is enforced structurally by the query API itself — there's no equivalent "forgot to call it once" failure mode, because the value never touches the query text at all.
Some injection techniques (particularly in numeric contexts, or certain database-specific syntax) don't require breaking out of a quoted string at all, so quote-escaping alone doesn't address them.
A parameterized query sends the query's structure to the database first, then binds the value separately at the protocol level. The value is never part of the text the SQL parser reads — there's no character sequence, no encoding trick, and no missed escape call that can change that, because escaping was never the mechanism keeping it safe in the first place.
For identifiers (table/column names) that can't be bound as parameters, yes — paired with a strict allow-list, not general-purpose escaping of arbitrary values.
A well-maintained escaping function reduces the bypass risk but doesn't remove the "one missed call breaks everything" structural weakness — parameterized queries remain the more robust default even with a trustworthy escaping implementation available.