The Bug Is the Way You Built the String

Injection is the oldest bug on any list you care to read, and it is still being written this week, in new code, by people who have heard of it. That is worth being curious about rather than smug about. A bug this well known that keeps shipping is usually being taught wrong.

It is normally taught as an attack: here is a payload, here is what it does, do not let it happen. That framing puts you on defence against a string. The useful framing is the opposite — it is a mistake with one cause, and you can simply stop making it.

Data that becomes code

A program keeps data and code in separate worlds. A name is data; the instruction that looks the name up is code. Injection is what happens when data crosses the border into code — when something a stranger typed stops being treated as a value and starts being treated as an instruction.

It crosses that border for one reason, every time: the program built its instruction by gluing strings together, and the stranger's text was one of the pieces. Once their text is part of the instruction, anything in it that reads as an instruction *is* one.

query = "select * from users where name = '" + input + "'"

input = "' OR 1=1 --"

Nothing malfunctioned

This is the part worth sitting with, and the part that changes how you read your own code. The injected query does not error. It does not crash the database or bypass a check. It is valid SQL, and the database executes it exactly as written, because that is the job.

1'        close the quote the application opened for you
2OR 1=1   add a condition of your own that is always true
3--       comment out whatever the application wrote next

No protection was defeated, because there was no protection. The query did what its text said, and somebody else wrote part of the text. There is nothing to patch except that.

The remedies that are not the fix

Injection attracts folk remedies, and leaning on them instead of the actual fix is how injectable code survives a review. Each of these gets proposed in every codebase eventually.

1escaping quotes    misses every input you forget to escape, and every
2                   encoding trick that reaches the parser anyway
3blocking keywords  "OR", "SELECT" - breaks real data, blocks nothing an
4                   attacker cannot spell around
5a web firewall     buys time, catches known payloads, and is not a fix -
6                   it is a smoke alarm, not a fireproof wall

The keyword denylist deserves a special mention, because it fails in both directions at once. It does not stop anybody who can spell around it, and it breaks your genuine data the first time an O'Brien joins the company. When a defence costs real users and buys nothing, that is not a tuning problem. It is evidence the approach is wrong.

The fix, which is less code

Write the query with a placeholder and hand the value over separately. The database treats it as a value and only ever as a value, because it never reaches the parser as SQL.

query = "select * from users where name = '" + input + "'"
run(query)

query = "select * from users where name = ?"
run(query, [input])

Notice what the safe version costs: nothing. It is *less* code than building the string by hand — you delete the quotes and the plus signs. Every language's database library supports it. "No time to fix it" rarely survives contact with the diff.

The shape generalises, which is the real lesson

Command injection, template injection, path traversal: same border, same cause, same cure in a different library. Learn the shape once on the simplest case and you will recognise it in code that looks nothing like this.