Objective
Verify that untrusted application input cannot alter the intended structure or meaning of commands, queries, expressions or instructions executed by downstream interpreters.
Injection occurs when an application constructs an interpreter-facing instruction from data that is not adequately separated from the instruction itself.
The assessment therefore focuses on the boundary between data and instructions. A vulnerability exists when attacker-controlled data can cross that boundary and influence the structure or execution of the interpreted operation.
Scope
Review application inputs that reach interpreters or interpreter-like components, including:
Prerequisites
| Authorization | Confirm authorization to perform active security testing against the application and its dependent services. |
|---|---|
| Application map | Identify forms, APIs, parameters, headers, cookies, uploads and other user-controlled inputs. |
| Test accounts | Prepare authorized accounts and test data appropriate to the application's roles and workflows. |
| Technology inventory | Identify relevant database engines, operating-system interfaces, frameworks, templating engines and external services. |
| Test environment | Prefer a controlled environment for injection testing, particularly where successful execution could modify data or invoke operating-system functionality. |
Methodology
Injection testing should begin by identifying where application-controlled data crosses into an interpreter. Testing should then determine whether the application's construction method preserves the intended separation between data and instructions.
| Review stage | Primary question |
|---|---|
| Input discovery | Which attacker-controlled values reach interpreter-facing functionality? |
| Sink identification | Which database, command processor, expression engine or parser consumes the value? |
| Construction analysis | Is data safely separated from the interpreter instruction? |
| Behavioral testing | Does controlled input change the intended behavior of the operation? |
| Impact analysis | What security boundary or data integrity property could be affected? |
| Remediation verification | Does the fix eliminate the interpreter influence rather than merely blocking one known payload? |
Test procedure
Input and sink mapping
Do not test every parameter blindly. First determine whether the value actually reaches an interpreter-sensitive operation.
| Input source | Potential sink | Review focus |
|---|---|---|
| Search parameter | Database query | Query construction and parameter binding |
| File name | OS command | Shell invocation and argument separation |
| Filter object | NoSQL query | Operator injection and type handling |
| Template value | Template engine | Context and evaluation behavior |
| Directory or lookup field | LDAP / XPath | Query construction and escaping strategy |
SQL injection
SQL injection should be assessed wherever user-controlled data is incorporated into SQL statements without reliable parameterization or equivalent safe query construction.
Preferred construction model
SELECT id, name
FROM users
WHERE username = ?Character escaping is context-sensitive and easy to implement incorrectly. Parameterized queries should normally be preferred because they preserve the separation between query structure and data.
NoSQL injection
NoSQL injection can occur when untrusted input is interpreted as query operators, expressions or other database-specific structures instead of being treated strictly as application data.
Determine whether an input expected to be a scalar value can instead be supplied as an object, array or other unexpected type.
Determine whether user input can introduce database-specific operators into a query.
Verify that application-controlled query structure is separated from user-controlled values.
Verify that request objects are explicitly mapped to permitted fields rather than directly passed to query APIs.
Operating-system command injection
Command injection occurs when attacker-controlled data can influence an operating-system command executed by the application.
A proof of vulnerability does not require deleting files, changing system configuration, creating persistence or accessing unrelated data. Use a controlled, non-destructive verification method.
Preferred design
Where possible, replace shell-based operations with direct library or operating-system APIs. If process execution is unavoidable, use APIs that accept a command and arguments as separate structured values and apply strict allowlists to permitted operations.
Other injection classes
Review directory-search filters and distinguished names constructed from untrusted input.
Review dynamically constructed XPath expressions and XML processing operations.
Determine whether user-controlled expressions can be evaluated rather than treated as ordinary data.
Determine whether untrusted input is placed into an executable template context.
Review query construction for GraphQL, search engines and other query languages.
Review application-specific parsers and domain languages for unsafe interpretation of user data.
Controlled reproduction
Reproduction should demonstrate a measurable change in interpreter behavior using the smallest possible non-destructive test case.
Baseline
GET /search?q=normal-value HTTP/1.1
Host: application.exampleControlled variation
GET /search?q=<controlled-test-input> HTTP/1.1
Host: application.exampleCompare the result with the baseline. A difference alone is not sufficient to establish injection. The tester must determine that the input influenced the interpreter rather than simply triggering normal validation or application error handling.
Do not define a finding merely because a known injection string produces an error. The professional test is to establish the data-to-instruction boundary, demonstrate interpreter influence and assess the resulting security impact.
Assessment
| Condition | Assessment consideration |
|---|---|
| Safe separation | Untrusted input remains data and cannot alter interpreter structure. |
| Suspected injection | Input produces interpreter-sensitive behavior requiring further confirmation. |
| Confirmed injection | Attacker-controlled data demonstrably influences the interpreter's instruction or query structure. |
| Exploitable injection | The injection permits a security-impacting outcome such as unauthorized data access, modification or command execution. |
| False positive | The observed behavior is caused by normal validation, error handling or another mechanism and does not demonstrate interpreter injection. |
Failure criteria
The application constructs a database query by incorporating user-controlled search input directly into the query structure. Controlled testing demonstrates that specially constructed input changes the database operation beyond the intended search value, confirming that attacker-controlled data is being interpreted as part of the query.
Remediation
- Prefer parameterized queries or prepared statements for SQL database operations.
- Use structured database APIs that keep query operators separate from user-controlled values.
- Avoid invoking a shell when a direct operating-system or library API can perform the required operation.
- When process execution is unavoidable, pass command arguments using structured process APIs rather than concatenating shell commands.
- Apply strict allowlists to operations that must be selected from a finite set of permitted actions.
- Use context-specific escaping only where the relevant interpreter requires it and where parameterization is unavailable.
- Do not rely on generic input filtering as the primary defense against injection.
- Validate input types and expected structure before constructing downstream operations.
- Apply least privilege to database accounts and operating-system processes so that a successful injection has limited impact.
- Centralize secure data-access patterns and prohibit unsafe query construction through development standards and code review.
A blocklist containing known metacharacters or previously observed payloads is not a robust general defense. Injection prevention should primarily preserve the structural separation between trusted instructions and untrusted data.
Post-remediation verification
User-controlled input remains data and cannot alter the structure or execution of the relevant interpreter operation.
The original injection or an equivalent interpreter influence remains reproducible.
The relevant interpreter sink or remediation could not be adequately evaluated.
Evidence requirements
Evidence should demonstrate the vulnerability without unnecessarily extracting data, modifying records, executing destructive commands or accessing unrelated systems.
Classification
| WebOTG procedure | WebOTG-CI-001 |
|---|---|
| OWASP category | A05:2025 — Injection |
| Procedure type | Interpreter-boundary and injection vulnerability assessment |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine according to the interpreter affected, privileges available, data or systems reachable, exploitability and resulting business impact. |
WebOTG-CI-001 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.
References
| Source | Relevance |
|---|---|
| OWASP Top 10:2025 — A05 | Primary category definition for Injection. |
| OWASP Web Security Testing Guide | Injection testing methodology and application security testing guidance. |
| OWASP SQL Injection Prevention Cheat Sheet | Guidance for preventing SQL injection through parameterized queries and safe database access patterns. |
| OWASP Command Injection Defense | Guidance for preventing operating-system command injection. |
| CWE | Common weakness classifications for injection-related vulnerabilities. |
WebOTG should maintain authoritative source references, document versions and review dates through its content management system so that this procedure can be updated independently from application code.