SQL injection

SQL injection exists wherever a query is assembled by joining strings together. The database receives one block of text and parses it into a command; it has no record of which characters the developer wrote and which arrived from a login form. Supply a value containing a quote and the right keywords and the parser reads them as instructions, because from its position they are indistinguishable from every other instruction in the statement. The defect is the concatenation itself, not the absence of a filter over it.

The commercial exposure is unusually direct. A single reachable injection point frequently yields the whole dataset rather than one record, and datasets are precisely what regulators, customers and acquirers ask about. Depending on the permissions the application connects with, it can also mean writing rows, dropping tables or reaching the host underneath. This is why the flaw keeps its place near the top of every serious risk list decades after the fix became well understood and effectively free to apply.

What actually closes it

• Parameterised statements. The query structure is sent to the database separately from the values, so nothing arriving from a user can be reinterpreted as syntax. This is the fix; everything else on this list is defence in depth.
• An allow-list for the parts that genuinely cannot be parameterised, such as a column name in a sort clause, where the only safe approach is to map input onto a fixed set of permitted identifiers.
• Least privilege on the connection. An account that cannot drop a table converts one class of catastrophe into an ordinary incident.
• Escaping treated as a last resort rather than a strategy, because every hand-rolled escape routine eventually meets an encoding its author did not anticipate.

An ORM does not make an application immune: raw query helpers, string-built fragments and dynamic ordering clauses reintroduce the same defect underneath a safer-looking API.