A05:2025 – Injection
Overview
Injection remains one of the most persistent and well-understood vulnerability classes in web application security, yet it continues to appear at scale in real-world systems. In the OWASP Top 10:2025, Injection holds its position as a critical risk because it directly targets how applications process untrusted input and translate it into commands, queries, or expressions.
At its core, an injection vulnerability occurs when an application allows user-controlled data to be interpreted as part of a command or query rather than as data. When this boundary between data and instructions is broken, the attacker gains influence over the application’s execution flow.
Injection is not limited to a single technology or protocol. It spans multiple layers of modern applications, including:
Databases (SQL, NoSQL)
Operating systems (command injection)
Application frameworks (ORM, expression languages)
Web browsers (Cross-Site Scripting)
APIs and backends (JSON, GraphQL, XML, XPath)
Template engines and server-side rendering
What makes injection particularly dangerous is that it abuses intended functionality. The application is doing exactly what it was designed to do — executing logic — but with attacker-controlled input altering that logic in unintended ways.
Why Injection Still Works in 2025
Injection vulnerabilities persist not because developers are unaware of them, but because modern applications are:
Highly dynamic
Heavily data-driven
Built on layers of abstractions
Constantly evolving
Injection flaws often appear when:
Input validation is incomplete or inconsistent
Queries or commands are constructed dynamically
Developers trust frameworks to “handle it safely”
Legacy patterns survive in new code
Edge cases bypass expected sanitization paths
In many cases, injection does not result from a single obvious mistake, but from small assumptions compounding across layers of the application.
Injection Is a Trust Boundary Failure
Injection vulnerabilities are fundamentally about trust boundaries.
Every time an application:
Accepts user input
Parses a request
Builds a query
Evaluates an expression
Executes a command
It crosses a boundary between untrusted input and trusted execution.
When that boundary is not strictly enforced, attackers can:
Alter database queries
Execute system commands
Inject scripts into rendered output
Manipulate backend logic
Extract or corrupt data
Injection succeeds when the application treats input as instructions.
Injection vs Other OWASP Categories
Unlike categories such as Broken Access Control or Cryptographic Failures, injection does not primarily rely on logic mistakes in authorization or encryption design. Instead, it exploits how input is processed and interpreted.
However, injection frequently chains with other weaknesses:
Injection + Broken Access Control → mass data exposure
Injection + Security Misconfiguration → full system compromise
Injection + Logging Failures → stealthy persistence
Injection + Insecure Design → systemic abuse
This makes injection a common entry point rather than a standalone issue.
Injection Is Broader Than SQL Injection
While SQL Injection remains a well-known example, focusing only on SQL misses the bigger picture.
Modern injection vectors include:
Cross-Site Scripting (XSS)
NoSQL Injection
OS Command Injection
Server-Side Template Injection (SSTI)
LDAP Injection
XPath / XML Injection
Expression Language Injection
ORM Injection
HTTP Header Injection
CRLF Injection
Each variant targets a different interpreter, but the underlying concept is identical: user input changes the structure or meaning of a command.
Why Injection Is Attractive to Attackers
From an offensive perspective, injection vulnerabilities are powerful because they often:
Require minimal privileges
Work pre-authentication or post-authentication
Provide direct data access
Allow code or command execution
Are easy to automate
Scale across large datasets
Injection attacks also tend to leave traces that look like normal application usage, especially when embedded in legitimate requests.
Injection in Modern Architectures
In modern web applications, injection frequently appears in:
APIs consumed by multiple clients
Microservices communicating internally
Server-side rendered templates
Search, filter, and reporting features
Export and import functionality
Admin panels and internal tools
APIs are especially prone to injection issues because:
They rely heavily on structured input (JSON, GraphQL)
They assume clients behave correctly
They often lack strict validation
They reuse logic across contexts
Attacker Perspective
From an attacker’s point of view, injection testing is about asking one question repeatedly:
“Where does my input get interpreted?”
If input influences:
a query
a command
a template
an expression
a filter
a transformation
Then it becomes a candidate for injection.
Injection is not about guessing payloads blindly. It is about understanding how the application builds and executes logic, then nudging that logic just enough to escape its intended boundaries.
What Is Injection?
Injection is a class of vulnerabilities that occurs when untrusted input is interpreted by an application as part of a command, query, or expression, rather than being treated strictly as data.
In practical terms, injection happens when an attacker is able to influence how the application builds or executes logic by supplying crafted input that alters the structure or meaning of an instruction. Instead of the application executing only what the developer intended, it executes a modified version of that logic, partially controlled by the attacker.
Injection is not a flaw in cryptography, authentication, or access control by itself. It is a failure to properly separate data from instructions.
The Core Problem: Data vs Instructions
Every application relies on interpreters:
SQL engines
Operating systems
Template engines
Expression evaluators
Browsers
Directory services
API query parsers
These interpreters expect input in a specific format. Injection vulnerabilities arise when user-controlled input is concatenated, embedded, or evaluated directly inside that format.
The moment user input can:
change query structure
terminate a command
introduce new instructions
escape intended boundaries
Injection becomes possible.
This means injection is not tied to one language, one database, or one framework. Any interpreter that processes attacker-controlled input is a potential target.
Injection Is an Interpretation Problem
A common misconception is that injection is about “bad characters” or “missing filters.” In reality, injection is about interpretation.
The application fails when:
input is interpreted in the wrong context
escaping is incomplete or context-agnostic
validation assumes input will behave “normally”
abstractions hide dangerous behavior
An application can validate input and still be vulnerable if that validation does not match the execution context.
Injection Across Application Layers
Injection vulnerabilities can appear at multiple layers of a modern application, including:
Database layer When user input modifies SQL, NoSQL, or ORM queries.
Operating system layer When input influences shell commands or system calls.
Application logic layer When expressions, filters, or conditions are evaluated dynamically.
Presentation layer When user input is rendered without proper output encoding.
Integration layer When APIs, XML, or structured queries are built dynamically.
The interpreter changes, but the flaw remains the same: user input crosses into execution logic.
Injection Does Not Require Advanced Exploitation
One of the reasons injection remains so prevalent is that exploitation often does not require:
memory corruption
race conditions
bypassing authentication
chaining vulnerabilities
In many cases, injection exploitation consists of:
modifying a parameter
adding special characters
changing request structure
abusing dynamic filters or search features
If the application does not strictly enforce boundaries, the injection succeeds naturally.
Injection Before and After Authentication
Injection vulnerabilities can exist:
before authentication, allowing anonymous attackers to interact with interpreters
after authentication, allowing low-privileged users to escalate impact
Authentication does not protect against injection. It often increases impact, because authenticated contexts usually have:
more privileges
access to sensitive data
trusted execution paths
This is why injection is frequently combined with:
Broken Access Control
Insecure Design
Logging and Detection Failures
Injection Is a Class, Not a Single Bug
Injection is not one vulnerability. It is a category that includes multiple variants depending on the interpreter being targeted.
Examples include:
SQL Injection
NoSQL Injection
OS Command Injection
Cross-Site Scripting (XSS)
Server-Side Template Injection (SSTI)
LDAP Injection
XPath / XML Injection
Expression Language Injection
ORM Injection
CRLF / Header Injection
Each variant has different payloads and techniques, but they all share the same root cause.
Attacker Perspective
From an offensive perspective, injection testing starts with one question:
“Where does my input get parsed, evaluated, or executed?”
If the answer is:
a query
a command
a template
an expression
a filter
a transformation
Then injection is a realistic possibility.
Injection exploitation is not about memorizing payloads. It is about understanding how the application constructs logic and then subtly altering that construction.
Common Injection Scenarios
Injection vulnerabilities tend to appear in predictable places, not because applications are poorly built, but because they rely on dynamic behavior. Anywhere an application builds queries, commands, or expressions at runtime becomes a potential injection surface.
Below are the most common injection scenarios observed in real-world applications under OWASP A05:2025, described from an offensive perspective.
SQL Injection
SQL Injection occurs when user input is incorporated into a database query in a way that allows the attacker to modify the query structure.
This typically happens when:
Queries are built using string concatenation
Input is not parameterized correctly
Dynamic filters or search features are implemented
ORM abstractions are trusted blindly
Example scenario:
A search or filter endpoint accepts a parameter such as id, email, or status, which is directly embedded into a SQL query. By manipulating that parameter, the attacker can alter the query logic, retrieve unauthorized data, or modify records.
Impact can include:
Full database read access
Authentication bypass
Data modification or deletion
In some cases, remote code execution through database features
Even in 2025, SQL injection still appears frequently due to legacy code, reporting features, and complex query logic.
NoSQL Injection
NoSQL Injection targets databases such as MongoDB, CouchDB, or Elasticsearch, where queries are often expressed as structured objects (JSON, BSON).
This commonly occurs when:
User input is directly mapped into query objects
Filters are dynamically constructed
Type validation is missing or weak
Example scenario:
An API expects a simple value like "username": "john", but instead accepts an object such as:
If the backend blindly trusts the structure, the attacker can bypass filters or authentication logic.
NoSQL injection is often overlooked because:
There is no visible query string
Developers assume structured formats are safe
Payloads look “valid” JSON
OS Command Injection
OS Command Injection occurs when user input is used to construct system-level commands executed by the operating system.
This usually appears in:
File processing features
Network utilities (ping, nslookup, traceroute)
Backup or maintenance scripts
Image or document processing
Example scenario: An application executes a command like:
If input is not properly handled, the attacker can inject additional commands using separators.
Impact is often severe:
Arbitrary command execution
Full server compromise
Lateral movement
From an attacker’s perspective, command injection is a direct path to system-level control.
Cross-Site Scripting (XSS)
Cross-Site Scripting occurs when user input is rendered in a browser without proper output encoding, allowing injected scripts to execute in the victim’s context.
XSS commonly appears in:
User profiles
Comments or messages
Search results
Error messages
Admin dashboards
Unlike other injection types, XSS targets the browser interpreter, not the backend.
Impact includes:
Session hijacking
Credential theft
Account takeover
Execution of actions on behalf of users
XSS remains prevalent because output encoding is context-specific and often misunderstood.
Server-Side Template Injection (SSTI)
SSTI occurs when user input is injected into a server-side template engine and evaluated as template logic.
This appears when:
Templates are rendered dynamically
User input is passed directly into template contexts
Developers assume templates are “safe”
Example scenario: An application allows customization of email templates, reports, or views. If input is evaluated rather than rendered as plain text, the attacker may gain code execution on the server.
SSTI often leads to:
Remote code execution
Full application compromise
LDAP Injection
LDAP Injection occurs when user input is used to build directory service queries without proper escaping.
This commonly affects:
Authentication systems
User lookup features
Enterprise integrations
Example scenario: A login form constructs an LDAP query using user-supplied credentials. By manipulating input, an attacker can alter the query logic and bypass authentication.
LDAP injection is less visible but still relevant in corporate and hybrid environments.
XPath / XML Injection
XPath or XML Injection occurs when user input is embedded into XML queries or documents without proper sanitization.
This appears in:
Legacy systems
SOAP-based services
XML-based APIs
Attackers can manipulate queries to:
Extract sensitive data
Bypass access controls
Alter logic conditions
Expression Language Injection
Some frameworks support expression languages to evaluate conditions or calculations dynamically.
Injection occurs when:
User input is evaluated as an expression
Expression parsing is exposed to external input
This can lead to:
Data leakage
Logic bypass
Code execution
Expression injection is often subtle and difficult to detect automatically.
HTTP Header and CRLF Injection
Header injection occurs when user input is used in HTTP headers without proper validation.
This can allow:
Response splitting
Header manipulation
Cache poisoning
CRLF injection abuses newline characters to inject additional headers or responses.
These issues are often underestimated but can enable serious downstream attacks.
Why These Scenarios Persist
Injection scenarios persist because:
Input flows through many layers
Validation is often partial
Context changes between layers
Framework abstractions hide execution details
Developers underestimate attacker creativity
From an attacker’s perspective, injection is about finding where input crosses into execution, not about guessing payloads randomly.
Testing Perspective (Offensive Mindset)
From an offensive perspective, injection testing is not about blindly throwing payloads at inputs and hoping something breaks. It is about understanding how the application processes input, how it builds internal logic, and where user-controlled data crosses into execution contexts.
The attacker mindset for injection can be summarized in one sentence:
“Where does my input stop being data and start becoming logic?”
Every successful injection exploit answers that question.
Start by Mapping Input Flow
Before testing payloads, the first step is to understand where input goes.
An attacker asks:
Where does this parameter end up?
Is it used in a query, command, template, or expression?
Does it influence filtering, sorting, or logic decisions?
Does it get transformed before execution?
This is why injection testing often starts with:
Search features
Filters
Sorting parameters
Reporting endpoints
Export/import functionality
Admin or internal tools
Any feature that dynamically adapts behavior based on input is suspicious by default.
Trust No Abstraction
Modern applications rely heavily on:
ORMs
Frameworks
Query builders
Serialization libraries
Template engines
From an offensive standpoint, abstractions are not security boundaries.
Attackers assume:
Parameterization may be incomplete
Escaping may be context-agnostic
Framework defaults may be unsafe
Edge cases may bypass safeguards
Instead of trusting that “the framework handles it,” attackers test whether it actually does.
Look for Dynamic Behavior
Injection thrives on dynamism.
Attackers focus on inputs that:
Modify query structure
Change filtering conditions
Control sorting or ordering
Affect template rendering
Influence command arguments
Alter expressions or conditions
Static values are less interesting. Dynamic behavior is where injection hides.
Test Incrementally, Not Aggressively
Effective injection testing is progressive.
Instead of starting with obvious payloads, attackers:
Slightly modify input
Observe differences in responses
Look for logic changes
Trigger errors or anomalies
Small changes often reveal:
Parsing behavior
Error handling differences
Backend assumptions
These signals guide further exploitation.
Observe Errors, Timing, and Behavior
Injection vulnerabilities often reveal themselves indirectly.
Attackers watch for:
Database errors
Stack traces
Unexpected response codes
Changes in response size
Delays or timing differences
Even when errors are suppressed, behavior changes can indicate injection paths.
Silence does not mean safety — it often means blind injection.
Treat APIs as Primary Targets
In modern applications, APIs are prime injection surfaces.
Attackers test APIs because:
They are less guarded than UIs
They assume trusted clients
They expose structured input
They often reuse logic across features
JSON-based APIs, GraphQL endpoints, and internal APIs are especially attractive because:
Input validation is frequently weak
Type assumptions can be abused
Filters and conditions are dynamic
Think Beyond SQL
A common mistake during testing is focusing only on SQL Injection.
From an offensive mindset, every interpreter is a target:
Databases
Operating systems
Template engines
Browsers
Directory services
Expression evaluators
If the application evaluates something dynamically, it is injectable until proven otherwise.
Injection Loves Business Logic
Injection often appears inside:
Search filters
Advanced queries
Reporting features
Admin dashboards
Configuration-driven logic
These areas are complex, change frequently, and are rarely tested exhaustively.
Attackers assume: “The more complex the logic, the higher the chance of injection.”
Combine Injection with Context
Injection becomes far more powerful when combined with:
Authentication context
Access control weaknesses
Misconfigurations
Logging gaps
A low-impact injection in isolation can become critical when chained with other weaknesses.
Final Offensive Principle
Injection testing is not about payloads. It is about control.
If attacker-controlled input can:
influence execution
modify logic
escape intended boundaries
Then injection exists, even if exploitation requires effort.
Hands-on Testing Checklist – Injection (A05:2025)
This checklist is intended for active offensive testing. It is not a list of payloads, but a structured way to systematically verify whether user-controlled input can escape its intended data boundary and influence execution logic.
The guiding principle is simple:
Assume every input is injectable until proven otherwise.
Final Attacker Mindset
Injection testing is about breaking the assumption that input is harmless.
If an application assumes:
“this value will always be safe”
“the framework escapes it”
“users won’t try that”
“this API is internal”
That assumption is your entry point.
Injection does not break systems — it reveals how they already work.
Last updated