What is the conceptual model of an injection attack?
Untrusted input reaches an interpreter that executes it as code instead of treating it as data.
* The injection model — untrusted input crosses a trust boundary into an interpreter, which executes it as code instead of treating it as data. *
Every injection tells the same three-step story, and it works for one reason: the vulnerable code hands the interpreter a single string that mixes its own instructions with the attacker's data. The interpreter has no way to tell which characters came from the programmer and which came from the user, so it parses all of them as language.
- An interface accepts untrusted input — a form field, a URL parameter, an uploaded file, an API payload, even a line written to a log.
- That input is forwarded to a subcomponent still glued into the surrounding command, rather than passed alongside it as a separate value.
- An interpreter or parser executes it — the injected fragment becomes part of the query, command or markup instead of a value inside it.
The line the payload steps over is the trust boundary: the point where data from outside reaches a component with a command interface — a SQL engine, a shell, an XPath processor, a browser's HTML parser. Everything arriving from the far side is attacker-controlled, so it must never arrive as code.
Why this one model covers so many attack names: SQL injection, OS command injection, XPath injection and XSS differ only in which interpreter sits behind the boundary. Recognise the shape and the defence follows — keep code and data in separate channels instead of concatenating them into one string.
Go deeper:
OWASP Top 10 (2021) — A03: Injection — injection as untrusted data reaching an interpreter as code.- OWASP Injection Prevention Cheat Sheet — the full injection family and the general defense pattern.
- OWASP — Injection Theory — why any component with a command interface is a candidate target.