Category: Attack Techniques
Injection Attacks
Also known as: Code Injection, Interpreter Injection, Command Injection
Simply put
An injection attack occurs when an attacker inserts unauthorized or malicious data into a program, query, or process in a way the application does not intend. The application then passes this data to an interpreter or execution environment, which processes it as a command rather than plain data. This can allow attackers to execute unintended commands, access unauthorized data, or compromise the affected system.
Formal definition
Injection attacks exploit insufficient separation between untrusted data and the commands or queries that an interpreter processes. When an application fails to correctly validate, sanitize, or parameterize externally supplied input, an attacker may craft input that alters the syntactic meaning of a command sent to a downstream interpreter, such as a SQL engine, OS shell, LDAP directory, or XML parser. The interpreter executes the attacker-controlled logic within the trust context of the application, potentially enabling unauthorized data access, remote command execution, or malware delivery. The attack surface includes any data channel through which untrusted input reaches an interpreter, including user-supplied form fields, HTTP headers, API parameters, and biometric or media inputs. Effective mitigations typically include parameterized queries, allowlist input validation, and least-privilege execution contexts, though the applicability of each control varies by interpreter type and deployment context.
Why it matters
Injection attacks represent one of the most persistent and consequential categories of vulnerability in application security. Because they exploit the fundamental trust that interpreters place in the commands and queries they receive, a successful injection attack typically operates within the full privilege context of the application, potentially granting an attacker unauthorized access to sensitive data, the ability to execute arbitrary commands, or a foothold for further compromise. The attack surface is broad, spanning any data channel through which untrusted input reaches an interpreter, including form fields, HTTP headers, API parameters, and less obvious inputs such as biometric or media data.
Who it's relevant to
Application Developers
Developers are on the front line of preventing injection vulnerabilities. The most effective controls, including parameterized queries, prepared statements, and allowlist input validation, must be applied at the code level during development. Understanding how each interpreter type processes input is essential to selecting the appropriate mitigation, since a control that is effective for SQL injection may not be sufficient for OS command injection or LDAP injection.
Security Engineers and AppSec Teams
Security engineers are responsible for establishing coding standards, reviewing code for injection-prone patterns, and selecting tooling to detect these issues. Static analysis tools can identify many common injection patterns at the code level but typically cannot detect vulnerabilities that depend on runtime data flow or deployment configuration. Dynamic testing and manual code review complement static analysis to reduce false negative rates and address scope boundaries that automated tools may miss.
Penetration Testers and Red Teams
Penetration testers actively probe applications for injection vulnerabilities by crafting and submitting malicious input across all available data channels. Because injection behavior often depends on how the application processes input at runtime, dynamic testing is particularly well suited to discovering these issues. Testers should evaluate not only common input vectors such as form fields and query parameters, but also less obvious channels including HTTP headers, file uploads, and API payloads.
Security Operations and Incident Responders
For security operations teams, injection attacks are relevant both as a detection challenge and as a common initial access vector in incident investigations. Web application firewalls and runtime monitoring controls may help detect or block injection attempts in many cases, though evasion techniques can reduce their effectiveness. Incident responders investigating a breach should consider injection as a plausible entry point when evidence points to unauthorized data access or unexpected command execution originating from the application tier.
Risk and Compliance Professionals
Injection vulnerabilities have appeared consistently in major vulnerability classification frameworks and are widely recognized as a high-severity risk category. Compliance programs and security assessments frequently require organizations to demonstrate that injection risks are identified and mitigated across their application portfolio. Risk professionals should ensure that injection is addressed in threat modeling activities and that remediation timelines reflect the potential severity of exploitation, which can include unauthorized data disclosure and full system compromise.
Inside Injection Attacks
Unsanitized User Input
The root condition enabling injection attacks, where attacker-controlled data is accepted by an application without adequate validation, sanitization, or encoding before being passed to an interpreter or execution context.
Interpreter or Execution Context
The backend system that processes the injected payload, such as a SQL database engine, OS shell, LDAP directory, XML parser, or HTML/JavaScript renderer. The specific interpreter determines the syntax and impact of a successful attack.
Payload
The malicious string or data sequence crafted by an attacker to alter the intended logic of a query, command, or document when processed by the target interpreter.
SQL Injection (SQLi)
A category of injection attack targeting relational database query logic, where attacker-supplied input is interpreted as SQL syntax, potentially enabling unauthorized data retrieval, modification, deletion, or authentication bypass.
Command Injection (OS Injection)
An attack in which unsanitized input is passed to a system shell or operating system command, allowing an attacker to execute arbitrary commands with the privileges of the application process.
Cross-Site Scripting (XSS)
An injection attack targeting the browser's HTML and JavaScript rendering context, where malicious scripts are injected into web content and executed in the context of other users' sessions.
LDAP Injection
An attack that manipulates LDAP query logic by embedding special characters in user-supplied input, typically used to bypass authentication or extract directory information.
XML/XPath Injection
An attack that alters the structure or logic of XML queries or XPath expressions by injecting malicious input, potentially enabling unauthorized data access or logic bypass within XML-based systems.
Parameterized Queries and Prepared Statements
A primary defensive control for SQL injection that separates query structure from user-supplied data, ensuring input is treated as a literal value rather than executable SQL syntax.
Output Encoding
A context-specific defensive technique that converts potentially dangerous characters into their safe representations before rendering in a target context, such as HTML entity encoding to prevent XSS.
Input Validation
The practice of enforcing expected format, type, length, and character set constraints on user-supplied data before processing, reducing but not eliminating injection risk when used as a sole control.
Allowlist (Whitelist) Approach
A validation strategy that permits only explicitly defined, known-safe input values or patterns, offering stronger injection defense than denylist-based filtering, which attempts to block known-bad patterns.
Common questions
Answers to the questions practitioners most commonly ask about Injection Attacks.
Does using a WAF protect my application from injection attacks?
A WAF provides a supplementary layer of defense and can block many known injection patterns at the network perimeter, but it does not constitute full protection against injection attacks. WAFs can be bypassed through encoding variations, novel payloads, or application-specific logic that the WAF rules do not anticipate. The primary defense against injection attacks is secure coding practices at the application layer, particularly parameterized queries and strict input validation. A WAF should be treated as a defense-in-depth measure, not a substitute for fixing injection vulnerabilities in the code itself.
If I validate and sanitize all user input, is my application safe from injection attacks?
Input validation and sanitization reduce risk significantly but do not eliminate injection vulnerabilities on their own. Sanitization can be incomplete or inconsistently applied, and certain injection contexts require context-aware output encoding rather than input filtering. For SQL injection specifically, parameterized queries or prepared statements are the recommended primary control because they separate code from data structurally, rather than relying on filtering logic that may have gaps. Input validation is best used as an additional layer alongside these structural controls, not as the sole defense.
How do I choose between parameterized queries and stored procedures to prevent SQL injection?
Both parameterized queries and stored procedures can effectively prevent SQL injection when implemented correctly. Parameterized queries enforce separation of SQL code and data at the driver or library level and are generally the more straightforward choice for most use cases. Stored procedures are acceptable when they do not internally construct dynamic SQL using concatenation. If a stored procedure builds dynamic SQL internally and executes it, it may reintroduce injection risk even if the outer call uses parameters. The choice should depend on your team's ability to implement and audit each approach consistently in your specific data access layer.
How should I prioritize injection vulnerabilities found during a code review or SAST scan?
Injection findings should generally be treated as high or critical severity because they can lead to data exfiltration, authentication bypass, or full system compromise depending on context. However, SAST tools may produce false positives, particularly when data flows through sanitization or parameterization logic that the tool cannot trace. Each finding should be validated by confirming whether untrusted input reaches a sensitive execution context without an adequate structural control in place. Prioritization should account for the sensitivity of the data or system accessible through the injection point, the exposure of the endpoint, and whether a structural fix such as parameterization is already partially in place.
What should I do if my application requires dynamic query construction and I cannot use parameterized queries?
When parameterized queries are not feasible, typically due to legacy system constraints or database features that do not support parameterization for certain clauses such as table or column names, the recommended approach is to use a strict allowlist for any dynamic components. Allowlists should map user-supplied identifiers to a predefined set of safe values controlled by the application, so that raw user input is never directly interpolated into the query. Additional controls include applying least-privilege database accounts, enabling query logging for anomaly detection, and conducting targeted code review for every location where dynamic construction occurs. These measures reduce risk but should be considered compensating controls rather than equivalents to parameterization.
How do injection attack risks differ between SQL databases and other injection contexts such as OS commands or LDAP queries?
The underlying principle is the same across injection types: untrusted input is interpreted as executable code or query syntax in a context where it should be treated as data. However, the specific controls, severity, and scope differ by context. OS command injection typically carries higher severity because it may grant access to the underlying system rather than just the database. LDAP injection and XML injection have their own syntax rules and require context-specific escaping or structural controls rather than SQL-specific parameterization. Each injection context requires separate evaluation of the relevant API, the available structural defenses for that technology, and the potential impact if exploited. A control that is effective for SQL injection does not automatically transfer to other injection types.
Common misconceptions
Escaping or filtering dangerous characters is sufficient to prevent injection attacks.
Character escaping and denylist filtering are fragile controls that can be bypassed through encoding variations, context switching, or edge cases not anticipated by the filter. Parameterized queries and context-aware output encoding address the underlying structural issue and are more reliable primary controls.
Injection vulnerabilities only affect SQL databases.
Injection attacks target any interpreter that processes user-supplied input as executable logic, including OS shells, LDAP directories, XML parsers, XPath engines, HTML and JavaScript renderers, and template engines. The class of vulnerability is defined by the trust boundary violation, not the specific backend technology.
Static analysis tools can reliably detect all injection vulnerabilities in a codebase.
Static analysis tools can identify many common injection patterns at the code level, such as direct concatenation of user input into queries or commands, but typically produce false positives and false negatives. They cannot fully evaluate injection risk introduced through runtime configuration, dynamic query construction, third-party libraries, or data flows that are only resolvable with execution context.
Best practices
Use parameterized queries or prepared statements for all database interactions rather than constructing queries through string concatenation with user-supplied input.
Apply context-aware output encoding when rendering user-controlled data in HTML, JavaScript, CSS, or URL contexts to prevent XSS and related injection in browser-rendered output.
Validate all user input against an allowlist of expected values, formats, and lengths as a defense-in-depth measure, recognizing that input validation alone is not sufficient as a primary injection control.
Avoid passing user-supplied input directly to OS commands, shell interpreters, or system APIs. Where system calls are necessary, use safe APIs that accept arguments as separate parameters rather than as a single shell-interpreted string.
Apply the principle of least privilege to all interpreter contexts, including database accounts, OS process users, and directory service credentials, so that a successful injection attack is constrained in the damage it can cause.
Integrate static analysis security testing (SAST) into the development pipeline to identify common injection patterns early, and supplement with dynamic analysis (DAST) and manual code review to address vulnerabilities that require runtime context to detect.