Injection is a class of vulnerability where attacker-controlled input is interpreted as code or a command instead of data. This can affect SQL queries, browser content, templates, or other execution paths. The core issue is insufficient validation, escaping, or contextual sanitisation before untrusted input is processed.
Expanded Definition
Injection refers to a family of flaws where untrusted input changes the intended syntax of an interpreter, parser, or execution layer. That interpreter may be a database engine, shell, template renderer, browser context, directory service, or API layer. The risk is not merely that input is “bad”; it is that the application treats attacker-controlled data as if it were trusted instructions.
Definitions vary across vendors when the term is used broadly, because “injection” can describe SQL injection, command injection, ldap injection, template injection, and similar patterns. The common thread is context loss: data is accepted in one format but executed in another. That is why parameterisation, strict allow-listing, escaping, and context-aware encoding matter more than generic input filtering. The relevant governance lens in NIST Cybersecurity Framework 2.0 is to reduce the likelihood that untrusted input can alter system behaviour, especially where business processes depend on automated parsing or dynamic code generation.
The most common misapplication is treating injection as a front-end validation problem, which occurs when teams sanitise only the user interface while backend parsers still execute attacker-controlled content.
Examples and Use Cases
Implementing injection resistance rigorously often introduces development constraints, requiring organisations to weigh developer flexibility against safer execution boundaries.
- SQL injection: a login or search field concatenates user input directly into a database query, allowing arbitrary query logic to be appended.
- Command injection: an application passes unsanitised parameters into a system shell, causing unintended operating system commands to run.
- Template injection: a templating engine interprets user-supplied syntax as instructions, which can expose data or trigger code execution.
- LDAP or directory injection: crafted input alters directory queries, leading to overbroad results or authentication bypass.
- Browser injection: content rendered without proper output encoding becomes executable script in the user’s browser.
For defenders, the operational test is whether input is ever allowed to alter structure, not just content. Guidance from the NIST Cybersecurity Framework 2.0 is especially useful when application teams need to connect secure development practices with risk reduction outcomes. In practice, the same defect may look different across languages and frameworks, but the fix pattern is usually consistent: separate data from instructions, validate at boundaries, and encode for the target context.
Why It Matters for Security Teams
Injection matters because it converts routine input handling into a direct path to confidentiality, integrity, and availability loss. A successful injection can expose databases, alter records, bypass access controls, or trigger command execution in the underlying environment. For security teams, the challenge is not only to detect known payloads, but to understand where dynamic interpretation exists across the stack.
This term also intersects with identity and access security when injected input manipulates authentication flows, session handling, or identity-related lookup logic. In IAM-adjacent systems, injection can undermine account discovery, approval workflows, or privileged automation if identity attributes are fed into queries without strict controls. In agentic AI environments, the same principle appears when tool inputs, prompts, or retrieved content are treated as trusted instructions rather than data. A separate but related operational concern is that application owners often focus on edge filtering while the real weakness sits inside a downstream interpreter.
Security teams should treat injection as a design and code-path issue, not a point solution problem. The most important remediation work is usually preventative and architectural, because once exploitation is underway, incident response must contend with stolen data, altered state, and possible lateral movement. Organisations typically encounter the true cost of injection only after a compromised service starts returning unexpected queries, at which point the issue becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Secure development and change control reduce injection exposure in applications and services. |
| NIST SP 800-53 Rev 5 | SI-10 | Input validation controls directly address injection by checking data before processing. |
| OWASP Agentic AI Top 10 | Agentic AI guidance covers prompt and tool injection risks in autonomous workflows. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when injection targets service credentials, tokens, or automation inputs. | |
| NIST AI RMF | AI RMF addresses misuse and robustness issues that include prompt and data injection paths. |
Protect machine identities and automation inputs so attacker-controlled data cannot redirect privileged actions.
