Home / Attacks & tests / Data validation testing
20 test cases
Data validation testing
Data validation testing examines what happens to input after the application accepts it. Every case in this category has the same shape: a value crosses from the caller into an interpreter — a browser, a database, a shell, a parser, a template engine — and the question is whether it arrives as data or as instruction.
What an attacker is trying to achieve
The attacker wants their input to be executed rather than stored or displayed. Which interpreter they reach determines what they gain: another user's session from a browser, the data set from a database, the host from a shell. The technique differs per interpreter; the underlying failure is the same one.
Test cases
20 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-INPV-01 Reflected Cross-Site Scripting
Objective — Determine whether input returned in the immediate response is placed into the page without encoding appropriate to the context it lands in.
How it is tested — Submit a distinctive marker into every parameter, header and path segment, and locate it in the response. For each reflection, identify the context — element text, attribute value, script literal, style, URL — and craft a payload valid for that context specifically. Test characters individually to establish which are encoded, stripped or passed, and try alternative encodings where a filter is present. Confirm execution in a real browser rather than inferring it from reflection.
Prerequisites — The entry-point inventory; a browser for confirmation; a proxy able to send characters the interface would escape.
Indicators — Script executing in a browser from a value supplied in the request; reflection into a script or attribute context without encoding; a filter defeated by an alternative encoding.
Coverage — WSTG-INPV-01V5.3.3CWE-79
Depth — Hybrid Scanners find reflected cases in ordinary parameters well. Contexts reached only through headers, or behind a partial filter, need manual work.
WEB-INPV-02 Stored Cross-Site Scripting
Objective — Determine whether input persisted by the application is later rendered to another user without encoding, so that the payload executes in their session rather than the submitter's.
How it is tested — Submit markers into every field that is stored, including those displayed only in administrative views, exports, notifications and logs. Then view each storage location as every role that can see it, since the rendering context differs per view and encoding is often applied on one and not another. Include fields whose display is delayed — reports, emails, audit trails — because these are rendered by code far from the input handler.
Prerequisites — Accounts covering every role that can view stored content, including an administrative one; a non-production environment, since the payload persists; a browser.
Indicators — A stored value executing when rendered to another user; encoding applied in the primary view but not in an administrative view, export or notification.
Coverage — WSTG-INPV-02V5.3.3CWE-79
Depth — Manual The submission and the execution happen in different places and often under different accounts, which a scanner does not connect.
WEB-INPV-03 HTTP Verb Tampering
Objective — Determine whether the method used to reach a route changes which protections apply to it, allowing a control bound to one verb to be bypassed by another.
How it is tested — For each protected route, re-issue the request using every other method the server accepts, including non-standard ones and the method-override headers frameworks honour. Establish whether authentication, authorisation, anti-forgery and input validation are applied per route or per method. Determine whether a method the application does not use reaches the same handler with fewer checks.
Prerequisites — The route list; accounts at differing privilege; a client able to issue arbitrary methods without the interface normalising them.
Indicators — A control enforced for one method and absent for another; a method-override header changing the effective operation; a state-changing handler reachable by a read method.
Coverage — WSTG-INPV-03V14.5.1V13.2.1CWE-650
Depth — Hybrid Method enumeration automates; recognising that two methods reach the same handler with different checks is a manual comparison.
WEB-INPV-04 HTTP Parameter Pollution and Manipulation
Objective — Determine how the application resolves a parameter supplied more than once, and whether that resolution differs between the layers that read it.
How it is tested — Submit the same parameter multiple times with different values, in the query string, the body, and both at once. Record which value each layer acts on — the edge proxy, the framework, the application, and any downstream service. Where they disagree, determine whether a value that passes a filter at one layer is the value acted on at another. Repeat for array and object notations the framework accepts.
Prerequisites — An entry point whose parameter value visibly affects the response; a proxy; ideally knowledge of the intermediary chain from architecture mapping.
Indicators — Different layers acting on different occurrences; a filter applied to one occurrence and bypassed by another; array notation accepted where a scalar was expected.
Coverage — WSTG-INPV-04V5.1.1V13.1.1CWE-235CWE-436
Depth — Manual The finding is a disagreement between layers, which only means something if the layers are known.
WEB-INPV-05 SQL Injection
Objective — Determine whether input reaches a database query as syntax rather than as a bound parameter, allowing the query's meaning to be changed by the caller.
How it is tested — Submit syntax-breaking characters into every parameter and observe changes in response, error text or timing. Where a difference appears, confirm it with a logically equivalent pair — a condition that is true and one that is false — to distinguish injection from coincidence. Where no output differs, use time-based confirmation. Extend to parameters used in ordering, grouping and identifiers, which are frequently concatenated even where values are bound.
Prerequisites — A non-production environment with a restorable database; agreement on which proofs may be run; the full entry-point inventory.
Indicators — Database errors from crafted input; identical responses for logically equivalent conditions and different ones for opposites; a controllable delay; data returned beyond what the function should return.
Coverage — WSTG-INPV-05V5.3.4CWE-89
Depth — Hybrid Detection automates well for value parameters. Identifier and ordering positions, and second-order cases where input is stored then used in a later query, need manual work.
WEB-INPV-06 LDAP Injection
Objective — Determine whether input reaches a directory query as filter syntax, allowing the filter's logic to be altered to return entries the caller should not see.
How it is tested — Identify functions likely backed by a directory — sign-in, user search, group membership, address lookup. Submit filter metacharacters and observe whether the result set changes in a way consistent with an altered filter rather than an altered search term. Test whether always-true constructions widen the result set, and whether attribute names can be introduced into a query that should only take a value.
Prerequisites — A function backed by a directory service; a non-production environment; an account permitted to perform the lookup.
Indicators — A result set widening in response to filter syntax; entries returned outside the intended scope; directory-specific errors disclosed.
Coverage — WSTG-INPV-06V5.3.7CWE-90
Depth — Manual Requires recognising that a search is directory-backed, which is rarely evident from the request alone.
WEB-INPV-07 ORM Injection
Objective — Determine whether input influences a query built through an object-relational layer in a way that changes which records are selected, even where the underlying values are parameterised.
How it is tested — Identify parameters that map to filtering, sorting or relation traversal rather than to values — field names, operators, expansion and include parameters, and filter expressions accepted as structured input. Substitute field names the caller should not be able to select on, including those on related records, and operators the interface never sends. Determine whether the layer will traverse a relation into data belonging to another principal.
Prerequisites — An API exposing filtering or expansion parameters; two accounts in different ownership scopes; a non-production environment.
Indicators — A field name accepted that the interface never sends; filtering on a related record's attribute; an expansion returning another principal's data; an operator changing the comparison semantics.
Coverage — WSTG-INPV-05V5.1.4CWE-89CWE-943
Depth — Manual The productive inputs are field and relation names specific to this data model, which have to be inferred from responses.
WEB-INPV-08 XML Injection
Objective — Determine whether input placed into an XML document alters that document's structure, and whether the parser resolves external references the caller can control.
How it is tested — Submit structural characters into fields that end up in XML and observe whether the document's shape changes or a parse error results. Where the application accepts XML directly, submit documents declaring external entities pointing at local and remote resources, and observe whether they are resolved. Test out-of-band resolution where no content is returned in the response, since blind resolution is common.
Prerequisites — An endpoint accepting or generating XML; a listener the target can reach for out-of-band confirmation; a non-production environment.
Indicators — Document structure altered by submitted characters; local file content returned; an out-of-band request arriving at the tester's listener; a parse error naming the entity.
Coverage — WSTG-INPV-07V13.3.1V5.5.2CWE-91CWE-611
Depth — Hybrid Entity resolution is partly automatable; the blind out-of-band case needs infrastructure a scanner does not have.
WEB-INPV-09 Server-Side Includes Injection
Objective — Determine whether input is interpreted by a server-side include processor before the response is returned, allowing file inclusion or command execution through directives in the page.
How it is tested — Establish whether the server processes includes, from extension handling and configuration observed earlier. Submit include directives into parameters that are reflected into pages served by that handler, and into any content stored and later rendered by it. Test both the file-inclusion and command-execution directive forms, and confirm through output appearing in the rendered page rather than in the raw response.
Prerequisites — A server with include processing enabled for the served content; a reflection or storage point in such content; a non-production environment.
Indicators — A directive evaluated rather than displayed; file content or command output appearing in the rendered page; a directive stripped, indicating the processor sees it.
Coverage — WSTG-INPV-08V5.2.5CWE-97
Depth — Manual Only applicable where include processing is enabled, which has to be established first rather than assumed.
WEB-INPV-10 XPath Injection
Objective — Determine whether input reaches an XPath expression as syntax, allowing the selection criteria to be widened beyond what the function intends.
How it is tested — Identify functions that query XML documents — authentication against an XML store, configuration lookups, document search. Submit expression metacharacters and observe whether the selection changes. Test always-true constructions to widen the result set, and, where responses differ only by success or failure, use those as an oracle to extract the document structure a character at a time.
Prerequisites — A function backed by an XML document store; a non-production environment; the ability to issue many requests for blind extraction.
Indicators — Selection widening in response to expression syntax; authentication succeeding without a valid credential; a boolean oracle distinguishing true from false conditions.
Coverage — WSTG-INPV-09V5.3.10CWE-643
Depth — Manual Recognising an XML-backed query from outside is the hard part, and it is not something a signature detects.
WEB-INPV-11 IMAP and SMTP Injection
Objective — Determine whether input reaches a mail protocol conversation as protocol syntax, allowing the caller to inject commands, headers or recipients.
How it is tested — Identify functions that send or retrieve mail — contact forms, invitations, notifications, password recovery, mailbox search. Submit line terminators followed by additional headers and commands into every field that reaches the message, including display names and subject lines. Determine whether additional recipients, altered headers or injected content appear in the delivered message.
Prerequisites — A mailbox the tester controls as the delivery target; a function that sends mail; a non-production environment so injected mail does not reach real recipients.
Indicators — An additional recipient receiving the message; headers present that the application did not set; message body content injected from a field intended for a header; protocol errors disclosed.
Coverage — WSTG-INPV-10V5.2.3CWE-93CWE-88
Depth — Manual Confirmation depends on inspecting delivered mail, which is outside the request-response cycle a scanner observes.
WEB-INPV-12 Code Injection
Objective — Determine whether input is evaluated as source by the application's own runtime, or as a template by its rendering engine, rather than treated as data.
How it is tested — Submit expressions valid in the identified runtime and template language — arithmetic whose result would be visible, and syntax that would error distinctively — into every reflected parameter and every stored field later rendered. Distinguish evaluation from reflection by confirming the result rather than the input appears. Extend to file names, configuration values and any field used to build a rendered document.
Prerequisites — The runtime and template engine identified during fingerprinting; a non-production environment; a reflection or storage point.
Indicators — An expression's result appearing rather than the expression; a runtime-specific error from submitted syntax; behaviour changing in a way only evaluation explains.
Coverage — WSTG-INPV-11WSTG-INPV-18V5.2.5CWE-94CWE-1336
Depth — Hybrid Common template engines are probed automatically; anything bespoke, and confirming evaluation rather than echo, is manual.
WEB-INPV-13 Local and Remote File Inclusion
Objective — Determine whether a parameter naming a resource can cause the application to include and process a file of the caller's choosing, from the local filesystem or a remote location.
How it is tested — Identify parameters selecting templates, pages, modules, languages or themes. Substitute paths to known local files, using traversal and encoded forms, and observe whether the content is processed rather than displayed. Where remote references are accepted, substitute a location the tester controls and observe whether it is fetched. Combine with upload functionality to establish whether uploaded content can be included.
Prerequisites — A parameter that names a resource; a listener the target can reach for the remote case; upload functionality where present; a non-production environment.
Indicators — Local file content processed or rendered; a request arriving at the tester's listener; uploaded content executed through an inclusion parameter.
Coverage — WSTG-ATHZ-01V12.3.2V12.3.6CWE-73CWE-829
Depth — Hybrid Local inclusion is partly automatable. The upload-then-include chain, and blind remote inclusion, require manual construction.
WEB-INPV-14 Command Injection
Objective — Determine whether input reaches an operating system command line, allowing the caller to run commands with the application's privileges.
How it is tested — Identify functions plausibly implemented by invoking an external program — file conversion, image processing, archive handling, network diagnostics, reporting. Submit command separators followed by a benign command whose effect is observable, preferring a controlled delay or an out-of-band request over anything that changes state. Test each separator and quoting form, and confirm blind cases by timing or by a request arriving at a tester-controlled listener.
Prerequisites — Explicit permission, since confirmation executes code on the host; a non-production environment; a listener for out-of-band confirmation.
Indicators — Command output in the response; a controllable delay matching an injected sleep; an out-of-band request from the application host.
Coverage — WSTG-INPV-12V5.3.8CWE-78CWE-77
Depth — Hybrid Signature probes find the obvious cases; identifying which feature shells out, and confirming blind execution safely, is manual.
WEB-INPV-15 Buffer Overflow
Objective — Determine whether the application or a native component it relies on mishandles input exceeding the size its buffers were sized for.
How it is tested — Identify components implemented in memory-unsafe languages — native modules, media and document processors, compression libraries, protocol parsers. Submit values substantially beyond expected lengths to each, and structured inputs declaring sizes inconsistent with their content. Observe for crashes, truncation, or behaviour indicating memory corruption rather than a validation refusal.
Prerequisites — A non-production environment, since confirmation may crash the service; explicit permission; visibility of service logs or restarts.
Indicators — A crash or restart following an oversized input; a declared length inconsistent with content being trusted; corrupted output rather than a clean rejection.
Coverage — V5.4.1CWE-120CWE-680
Depth — Manual Rare in managed web stacks and confined to native components, so the work is identifying whether such a component is in the path at all.
WEB-INPV-16 Heap Overflow
Objective — Determine whether dynamically allocated memory in a native component can be made to overflow through input the application accepts.
How it is tested — Target components that allocate based on values taken from input — image and document parsers, decompression routines, protocol decoders. Submit inputs whose declared dimensions or lengths disagree with their actual content, and values chosen to make an allocation calculation wrap or round. Observe process behaviour for corruption rather than for a validation error.
Prerequisites — A native processing component in the request path; a non-production environment; permission and log visibility, since confirmation may crash the service.
Indicators — A crash traced to allocation or copy; output corrupted in a manner consistent with adjacent memory; a declared size accepted without being reconciled against content.
Coverage — V5.4.1CWE-122CWE-680
Depth — Manual Requires reasoning about allocation from outside the process; no scanner signature reaches this.
WEB-INPV-17 Stack Overflow
Objective — Determine whether input can drive a native component's stack beyond its bounds, through oversized local copies or uncontrolled recursion.
How it is tested — Submit oversized values to native components, and deeply nested structured input — nested JSON, XML, archives and expressions — to any parser that recurses. Increase nesting depth progressively to find the point at which the parser fails, and establish whether it fails cleanly with an error or terminates the process.
Prerequisites — A non-production environment; permission, since confirmation may terminate the process; the ability to observe whether the service restarted.
Indicators — Process termination at a particular nesting depth rather than a clean depth-limit error; a crash following an oversized value; no configured limit on nesting depth.
Coverage — V5.4.1CWE-121CWE-674
Depth — Manual Nesting-depth probing is easy to run but has to be bounded deliberately, since the confirming result is a denial of service.
WEB-INPV-18 Format String Manipulation
Objective — Determine whether input reaches a formatting function as the format specification rather than as an argument to it, permitting memory disclosure or corruption.
How it is tested — Submit format specifiers into fields likely to be logged or rendered by a native component, particularly error messages, log entries and diagnostic output that echo caller-supplied values. Observe whether specifiers are displayed literally or interpreted. Where interpretation occurs, distinguish disclosure from corruption before proceeding, and stop at demonstration.
Prerequisites — A native component that formats caller-supplied strings; visibility of the output, which is often a log rather than a response; a non-production environment.
Indicators — A format specifier interpreted rather than displayed; memory content or pointer-like values in output; a crash following specifier submission.
Coverage — WSTG-INPV-13V5.4.2CWE-134
Depth — Manual Applies only to native formatting; confirmation usually requires reading logs rather than responses.
WEB-INPV-19 Incubated Vulnerabilities
Objective — Determine whether input accepted at one point is later used unsafely by a different component, so that the defect is not observable at the point of submission.
How it is tested — Seed distinctive markers into every stored field, then exercise every downstream consumer — administrative views, exports, scheduled reports, notifications, log viewers, integrations — and observe where each marker resurfaces and in what context. Where a marker reaches an interpreter, submit a payload valid for that interpreter instead. Allow for delay: some consumers run on a schedule rather than on request.
Prerequisites — Accounts covering every consuming view including administrative; a non-production environment; enough time for scheduled consumers to run.
Indicators — A marker appearing in a context the input handler did not anticipate; encoding applied at submission but not at the consumption point; a payload executing in a scheduled job or report.
Coverage — WSTG-INPV-14V5.3.3CWE-79CWE-20
Depth — Manual The whole category is defined by separation between cause and effect, which is precisely what request-response scanning cannot follow.
WEB-INPV-20 HTTP Splitting and Smuggling
Objective — Determine whether the caller can influence message framing, so that intermediary and origin disagree about where one request or response ends and the next begins.
How it is tested — Submit line terminators into values placed into response headers — redirect targets, cookie values, custom headers — and observe whether the response splits. For request smuggling, send requests with conflicting or obfuscated length declarations and observe whether the front end and back end resolve them differently, using timing and response-queue effects for confirmation. Restrict to a non-production environment, since a successful test poisons other users' responses.
Prerequisites — A non-production environment and explicit permission, because confirmation affects concurrent traffic; knowledge of the intermediary chain; a client that does not normalise the request.
Indicators — Headers or a second response injected from a parameter; front end and back end disagreeing on message length; a response arriving that belongs to another request.
Coverage — WSTG-INPV-15V13.1.1CWE-113CWE-444
Depth — Manual Confirmation is disruptive by nature and demands a controlled environment and a client that will send exactly what it is told to.
What we need from you
The complete entry-point inventory, including parameters the interface never varies and headers the application reads; accounts at each role; a non-production environment with a restorable database, because proving an injection generally means changing something; and agreement on which destructive proofs are permitted.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-INPV-01 — Testing for Reflected Cross Site Scripting
- V5.3.3 — Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
- CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
- WSTG-INPV-02 — Testing for Stored Cross Site Scripting
- WSTG-INPV-03 — Testing for HTTP Verb Tampering
- V14.5.1 — Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.
- V13.2.1 — Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.
- CWE-650 — Trusting HTTP Permission Methods on the Server Side
- WSTG-INPV-04 — Testing for HTTP Parameter pollution
- V5.1.1 — Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).
- V13.1.1 — Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.
- CWE-235 — Improper Handling of Extra Parameters
- CWE-436 — Interpretation Conflict
- WSTG-INPV-05 — Testing for SQL Injection
- V5.3.4 — Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.
- CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
- WSTG-INPV-06 — Testing for LDAP Injection
- V5.3.7 — Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.
- CWE-90 — Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
- V5.1.4 — Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).
- CWE-943 — Improper Neutralization of Special Elements in Data Query Logic
- WSTG-INPV-07 — Testing for XML Injection
- V13.3.1 — Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.
- V5.5.2 — Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.
- CWE-91 — XML Injection (aka Blind XPath Injection)
- CWE-611 — Improper Restriction of XML External Entity Reference
- WSTG-INPV-08 — Testing for SSI Injection
- V5.2.5 — Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.
- CWE-97 — Improper Neutralization of Server-Side Includes (SSI) Within a Web Page
- WSTG-INPV-09 — Testing for XPath Injection
- V5.3.10 — Verify that the application protects against XPath injection or XML injection attacks.
- CWE-643 — Improper Neutralization of Data within XPath Expressions ('XPath Injection')
- WSTG-INPV-10 — Testing for IMAP SMTP Injection
- V5.2.3 — Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
- CWE-93 — Improper Neutralization of CRLF Sequences ('CRLF Injection')
- CWE-88 — Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
- WSTG-INPV-11 — Testing for Code Injection
- WSTG-INPV-18 — Testing for Server-Side Template Injection
- CWE-94 — Improper Control of Generation of Code ('Code Injection')
- CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine
- WSTG-ATHZ-01 — Testing Directory Traversal File Include
- V12.3.2 — Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).
- V12.3.6 — Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.
- CWE-73 — External Control of File Name or Path
- CWE-829 — Inclusion of Functionality from Untrusted Control Sphere
- WSTG-INPV-12 — Testing for Command Injection
- V5.3.8 — Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.
- CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
- CWE-77 — Improper Neutralization of Special Elements used in a Command ('Command Injection')
- V5.4.1 — Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.
- CWE-120 — Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
- CWE-680 — Integer Overflow to Buffer Overflow
- CWE-122 — Heap-based Buffer Overflow
- CWE-121 — Stack-based Buffer Overflow
- CWE-674 — Uncontrolled Recursion
- WSTG-INPV-13 — Testing for Format String Injection
- V5.4.2 — Verify that format strings do not take potentially hostile input, and are constant.
- CWE-134 — Use of Externally-Controlled Format String
- WSTG-INPV-14 — Testing for Incubated Vulnerabilities
- CWE-20 — Improper Input Validation
- WSTG-INPV-15 — Testing for HTTP Splitting Smuggling
- CWE-113 — Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
- CWE-444 — Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.