📝 WSTG-INPV: Input Validation Testing

OWASP Web Security Testing Guide v4.2

By FixTheVuln Team Sources: OWASP WSTG v4.2
← OWASP WSTG Guide

Input validation is the most critical defense in web application security. This category contains 19 tests covering every major injection attack class, from cross-site scripting and SQL injection to server-side request forgery and template injection. Each test examines a different way that untrusted user input can be weaponized to compromise the application, its users, or its underlying infrastructure. Input validation vulnerabilities consistently dominate real-world breach reports because they can lead to data theft, code execution, and complete system compromise. For penetration testers and bug bounty hunters, mastering these techniques is essential since injection vulnerabilities typically command the highest severity ratings and payouts. Cert candidates will encounter these concepts heavily in CEH, OSCP, and GWAPT examinations.

Difficulty: Advanced 19 test cases

OWASP Top 10 Mapping

This testing category relates to the following OWASP Top 10 2021 categories:

A03A10

Quick Reference

Test ID Name CWEs Difficulty
WSTG-INPV-01Reflected XSSCWE-79Advanced
WSTG-INPV-02Stored XSSCWE-79Advanced
WSTG-INPV-03HTTP Verb TamperingCWE-288Advanced
WSTG-INPV-04HTTP Parameter PollutionCWE-235Advanced
WSTG-INPV-05SQL InjectionCWE-89Advanced
WSTG-INPV-06LDAP InjectionCWE-90Advanced
WSTG-INPV-07XML InjectionCWE-611, CWE-91Advanced
WSTG-INPV-08SSI InjectionCWE-97Advanced
WSTG-INPV-09XPath InjectionCWE-643Advanced
WSTG-INPV-10IMAP/SMTP InjectionCWE-93Advanced
WSTG-INPV-11Code InjectionCWE-94Advanced
WSTG-INPV-12Command InjectionCWE-78Advanced
WSTG-INPV-13Format String InjectionCWE-134Advanced
WSTG-INPV-14Incubated VulnerabilityCWE-79, CWE-89Advanced
WSTG-INPV-15HTTP Splitting/SmugglingCWE-113, CWE-444Advanced
WSTG-INPV-16HTTP Incoming RequestsCWE-20Advanced
WSTG-INPV-17Host Header InjectionCWE-644Advanced
WSTG-INPV-18SSTICWE-94, CWE-1336Advanced
WSTG-INPV-19SSRFCWE-918Advanced

Detailed Test Cases

WSTG-INPV-01: Reflected XSS

Advanced

Reflected XSS testing checks if user input is immediately returned in the server's response without proper encoding. An attacker crafts a malicious URL containing JavaScript that executes in the victim's browser when they click the link, potentially stealing session tokens or performing actions on their behalf.

Why it matters: Reflected XSS is one of the most common web vulnerabilities and enables session hijacking, credential theft, and phishing attacks. Because the payload is delivered via a URL, it can be spread through phishing emails, social media, or watering hole attacks.

What to Check

  • Test all URL parameters with basic XSS payloads (<script>alert(1)</script>)
  • Check search fields, error messages, and any reflected input for encoding
  • Test for XSS in different HTML contexts (attribute, JavaScript, CSS, URL)
  • Try encoding bypass techniques (HTML entities, URL encoding, Unicode)
  • Verify that Content-Type headers and Content-Security-Policy prevent execution
Tools: Burp Suite OWASP ZAP XSStrike Dalfox
CWE-79

WSTG-INPV-02: Stored XSS

Advanced

Stored XSS testing checks if user input is saved by the application (in a database, file, or cache) and later displayed to other users without proper encoding. Unlike reflected XSS, stored XSS does not require victim interaction with a malicious link since the payload is served from the application itself.

Why it matters: Stored XSS is more dangerous than reflected XSS because the malicious payload persists in the application and automatically executes for every user who views the affected page. A single stored XSS vulnerability in a popular feature can compromise thousands of users.

What to Check

  • Test all user-input fields that store and display data (comments, profiles, messages)
  • Check file upload names and metadata for XSS in filenames displayed on the page
  • Test rich text editors for XSS through HTML/Markdown input
  • Verify that stored data is encoded when displayed in all contexts
  • Check administrative panels that display user-submitted data
Tools: Burp Suite OWASP ZAP XSStrike BeEF
CWE-79

WSTG-INPV-03: HTTP Verb Tampering

Advanced

HTTP verb tampering tests whether changing the HTTP method (GET, POST, PUT, HEAD, etc.) on a request can bypass security controls. Some applications and middleware only enforce authentication or authorization on specific HTTP methods, leaving others unprotected.

Why it matters: Security controls that only apply to specific HTTP methods can be trivially bypassed. For example, a web application firewall might only inspect POST requests for SQL injection, allowing the same attack through a PUT request. This is a common misconfiguration in access control implementations.

What to Check

  • Replay protected requests using different HTTP methods (GET, POST, PUT, PATCH, DELETE)
  • Test if changing the method bypasses authentication or authorization checks
  • Check if the application responds differently to unexpected HTTP methods
  • Test for method override using X-HTTP-Method-Override header
  • Verify that security controls apply uniformly across all HTTP methods
Tools: Burp Suite curl OWASP ZAP
CWE-288

WSTG-INPV-04: HTTP Parameter Pollution

Advanced

HTTP Parameter Pollution (HPP) testing checks how the application handles duplicate parameters in the same request. Different web servers and frameworks handle duplicate parameters differently (first value, last value, concatenated, or array), which can be exploited to bypass validation or manipulate application logic.

Why it matters: HPP can bypass web application firewalls and input validation by splitting malicious input across duplicate parameters that get reassembled on the server. It can also manipulate application logic when different components parse duplicate parameters differently.

What to Check

  • Submit duplicate parameters with the same name but different values
  • Test how the application and server handle duplicate parameters (first wins, last wins, concat)
  • Try splitting injection payloads across duplicate parameters
  • Test HPP in query strings, POST body, and cookies simultaneously
  • Check if WAF rules can be bypassed through parameter pollution
Tools: Burp Suite OWASP ZAP Custom scripts
CWE-235

WSTG-INPV-05: SQL Injection

Advanced

SQL injection testing checks whether user input is incorporated into SQL queries without proper parameterization or sanitization. Successful SQL injection can read, modify, or delete database contents, bypass authentication, and in some cases execute operating system commands.

Why it matters: SQL injection has been responsible for some of the largest data breaches in history, exposing millions of records. It can lead to complete database compromise, authentication bypass, data exfiltration, and in some configurations, remote code execution on the database server.

What to Check

  • Test all input parameters with SQL metacharacters (single quote, double quote, semicolon)
  • Check for error-based, union-based, blind, and time-based SQL injection techniques
  • Test numeric, string, and wildcard parameter types
  • Look for second-order SQL injection where stored input is used in later queries
  • Test for SQL injection in HTTP headers, cookies, and JSON/XML request bodies
Tools: sqlmap Burp Suite OWASP ZAP Havij
CWE-89

WSTG-INPV-06: LDAP Injection

Advanced

LDAP injection testing checks whether user input is used in LDAP queries without proper sanitization. LDAP (Lightweight Directory Access Protocol) is commonly used for authentication and directory lookups in enterprise environments, and injection can bypass authentication or extract directory data.

Why it matters: LDAP injection can bypass authentication in enterprise applications that use Active Directory or other LDAP directories. It can also extract sensitive directory information including user lists, email addresses, organizational structures, and group memberships.

What to Check

  • Test login and search fields with LDAP metacharacters (*, (, ), \, NUL)
  • Try authentication bypass using LDAP injection (e.g., user=*)(uid=*)(&password=anything)
  • Test for information extraction by manipulating LDAP filter expressions
  • Check if the application uses parameterized LDAP queries or string concatenation
  • Test for both AND-based and OR-based LDAP injection techniques
Tools: Burp Suite Custom scripts OWASP ZAP ldapsearch
CWE-90

WSTG-INPV-07: XML Injection

Advanced

XML injection testing checks whether user input is embedded in XML documents without proper encoding, allowing attackers to modify XML structure. This includes XML External Entity (XXE) attacks that can read files, perform SSRF, or cause denial of service.

Why it matters: XML injection and XXE attacks can read arbitrary files from the server, perform server-side request forgery to internal services, exfiltrate data through out-of-band channels, and cause denial of service through billion laughs or recursive entity expansion attacks.

What to Check

  • Test for XML External Entity (XXE) injection to read local files
  • Check for blind XXE using out-of-band data exfiltration techniques
  • Test XML input for entity expansion denial of service (billion laughs)
  • Verify that XML parsers have external entity processing disabled
  • Test SOAP endpoints for XML injection in parameters
Tools: Burp Suite OWASP ZAP XXEinjector Custom XML payloads
CWE-611 CWE-91

WSTG-INPV-08: SSI Injection

Advanced

Server-Side Includes (SSI) injection testing checks whether user input is processed by the SSI engine, allowing attackers to inject SSI directives that execute commands, include files, or display server information. SSI is a legacy technology still found in some web servers.

Why it matters: SSI injection can lead to remote code execution if the web server processes SSI directives in user-controlled content. While less common in modern applications, legacy systems and certain hosting configurations still support SSI processing.

What to Check

  • Test input fields with SSI directives (<!--#exec cmd="command" -->)
  • Check if .shtml or .stm file extensions are processed for SSI
  • Test for SSI injection in file upload names and content
  • Verify that the web server is configured to only process SSI in designated file types
  • Check error pages and dynamic content for SSI processing
Tools: Burp Suite curl Custom payloads
CWE-97

WSTG-INPV-09: XPath Injection

Advanced

XPath injection testing checks whether user input is used in XPath queries against XML data stores without proper sanitization. Similar to SQL injection but targeting XML databases, XPath injection can bypass authentication and extract data from XML documents.

Why it matters: XPath injection can bypass authentication and extract all data from XML-based data stores. Unlike SQL injection, XPath has no permission model, so a successful injection can always access the entire XML document. Applications using XML for configuration or data storage are at risk.

What to Check

  • Test input fields with XPath metacharacters (single quote, double quote, //, ..)
  • Try authentication bypass with tautology-based XPath injection (1=1)
  • Test for blind XPath injection using boolean conditions and substring extraction
  • Check if the application uses XML databases or XPath for data retrieval
  • Verify that XPath queries use parameterized expressions rather than concatenation
Tools: Burp Suite Custom scripts xcat
CWE-643

WSTG-INPV-10: IMAP/SMTP Injection

Advanced

IMAP/SMTP injection testing checks whether user input is incorporated into email-related commands without sanitization. This can allow attackers to inject email commands through webmail interfaces, contact forms, or password reset functions that interact with mail servers.

Why it matters: Email injection can allow attackers to send emails as the application (spam, phishing), read other users' emails through IMAP injection, modify mailbox contents, or exfiltrate data through crafted email messages sent to attacker-controlled addresses.

What to Check

  • Test contact forms and feedback features for email header injection (\r\n)
  • Check if user input is used in IMAP commands for webmail applications
  • Test for SMTP injection through newline characters in email fields
  • Verify that email addresses are validated before use in mail commands
  • Test password reset and notification features for email injection
Tools: Burp Suite Custom scripts Telnet to SMTP server
CWE-93

WSTG-INPV-11: Code Injection

Advanced

Code injection testing checks whether user input is evaluated as code by the application's runtime environment. This includes injection into interpreted languages like PHP, Python, Ruby, and JavaScript where functions like eval(), exec(), or system() process user-supplied data.

Why it matters: Code injection provides direct code execution on the server, which is typically the most severe class of vulnerability. An attacker who can inject code gains the full capabilities of the programming language, including file system access, network operations, and command execution.

What to Check

  • Test parameters for server-side code injection (PHP, Python, Ruby, Node.js)
  • Look for eval(), exec(), system(), or similar dangerous functions processing user input
  • Test for code injection through deserialization of untrusted data
  • Check for expression language injection in framework-specific contexts
  • Verify that dynamic code evaluation is not used with user-controlled input
Tools: Burp Suite Commix Custom payloads OWASP ZAP
CWE-94

WSTG-INPV-12: Command Injection

Advanced

Command injection (OS command injection) testing checks whether user input is passed to operating system commands without proper sanitization. Successful exploitation allows attackers to execute arbitrary commands on the server with the privileges of the web application.

Why it matters: Command injection provides direct access to the underlying operating system. Attackers can read files, modify data, install backdoors, pivot to internal networks, or completely take over the server. It is one of the most severe vulnerability classes.

What to Check

  • Test parameters with command separator characters (;, |, &&, ||, `, $())
  • Look for application features that interact with the OS (ping, traceroute, file operations)
  • Test for blind command injection using time delays (sleep, ping -c)
  • Try out-of-band data exfiltration through DNS or HTTP callbacks
  • Check for command injection in file upload names and processing pipelines
Tools: Commix Burp Suite Custom payloads OWASP ZAP
CWE-78

WSTG-INPV-13: Format String Injection

Advanced

Format string injection testing checks whether user input is used as a format string parameter in functions like printf() in C/C++ applications. This can be exploited to read from and write to memory, crash the application, or achieve code execution.

Why it matters: Format string vulnerabilities can lead to information disclosure, denial of service, and arbitrary code execution. While less common in modern web applications, they still appear in applications with native code components, embedded systems, and legacy C/C++ web services.

What to Check

  • Test input parameters with format string specifiers (%s, %x, %n, %p)
  • Look for applications with C/C++ backends that use printf-family functions
  • Test for information leakage through %x or %p reading stack memory
  • Check CGI applications and native code web services for format string issues
  • Verify that user input is never used as the format string argument
Tools: Burp Suite Custom payloads GDB for backend analysis
CWE-134

WSTG-INPV-14: Incubated Vulnerability

Advanced

Incubated vulnerability testing checks for attacks where malicious input is stored in one part of the application and triggered later in a different context. This includes second-order injection attacks where stored data is used in SQL queries, file operations, or displayed to other users.

Why it matters: Incubated vulnerabilities are harder to detect because the injection point and the execution point are separated in time and location within the application. Automated scanners often miss these because they test input and output in the same request, not across different workflows.

What to Check

  • Trace how stored user input is used in subsequent application operations
  • Test for second-order SQL injection in stored data processed by backend jobs
  • Check if uploaded files or data trigger processing pipelines that may be vulnerable
  • Look for stored input used in email templates, report generation, or data exports
  • Test registration data that might be used in administrative interfaces without encoding
Tools: Burp Suite Manual code review Application-specific testing
CWE-79 CWE-89

WSTG-INPV-15: HTTP Splitting/Smuggling

Advanced

HTTP splitting and smuggling testing checks whether user input can inject headers or manipulate request boundaries in HTTP traffic. HTTP request smuggling exploits differences in how front-end and back-end servers parse HTTP requests to bypass security controls.

Why it matters: HTTP request smuggling can bypass web application firewalls, access controls, and routing rules by causing front-end and back-end servers to disagree about request boundaries. It can lead to cache poisoning, session hijacking, and request routing manipulation.

What to Check

  • Test for HTTP response splitting by injecting CRLF characters in parameters
  • Check for HTTP request smuggling using Content-Length/Transfer-Encoding conflicts
  • Test for CL.TE and TE.CL smuggling variants
  • Verify that the application rejects requests with ambiguous Content-Length/Transfer-Encoding
  • Check if user input can inject HTTP headers through CRLF injection
Tools: Burp Suite HTTP Request Smuggler smuggler.py Custom scripts
CWE-113 CWE-444

WSTG-INPV-16: HTTP Incoming Requests

Advanced

This test examines how the application handles and validates incoming HTTP requests, including unusual or malformed requests. It checks whether the application properly validates request structure, encoding, and content before processing.

Why it matters: Applications that do not properly validate incoming HTTP requests may be vulnerable to request manipulation, encoding-based bypasses, or protocol-level attacks. Strict request validation is an important defense-in-depth measure.

What to Check

  • Test how the application handles malformed HTTP requests
  • Check processing of requests with unusual encodings (UTF-7, double URL encoding)
  • Verify that the application validates Content-Type headers match actual content
  • Test for request body processing differences between content types
  • Check how the application handles oversized requests and headers
Tools: Burp Suite curl Custom HTTP clients OWASP ZAP
CWE-20

WSTG-INPV-17: Host Header Injection

Advanced

Host header injection testing checks whether the application trusts the Host header from user requests for security-sensitive operations like password reset links, cache keys, or server-side redirects. An attacker can manipulate the Host header to poison web caches or steal password reset tokens.

Why it matters: Host header injection can lead to password reset poisoning (where reset links point to attacker-controlled domains), web cache poisoning, and server-side request routing manipulation. Applications that use the Host header to generate URLs are particularly vulnerable.

What to Check

  • Modify the Host header in password reset requests to an attacker-controlled domain
  • Test for web cache poisoning by changing the Host header and checking cached responses
  • Check for SSRF through absolute URL handling with a modified Host header
  • Test X-Forwarded-Host and X-Host headers that may override the original Host
  • Verify that the application validates the Host header against a whitelist
Tools: Burp Suite curl Custom scripts
CWE-644

WSTG-INPV-18: SSTI

Advanced

Server-Side Template Injection (SSTI) testing checks whether user input is embedded in server-side templates (Jinja2, Twig, Freemarker, etc.) without proper sanitization. SSTI can escalate from information disclosure to remote code execution depending on the template engine.

Why it matters: SSTI vulnerabilities are especially dangerous because template engines often have access to server-side objects and methods. Depending on the template engine, SSTI can be escalated from simple math expressions to reading files, executing commands, and achieving full server compromise.

What to Check

  • Test input fields with template syntax for common engines ({{7*7}}, ${7*7}, #{7*7})
  • Identify the template engine from error messages or expression evaluation
  • Test for code execution through template engine-specific object chains
  • Check if user input is rendered in templates for emails, reports, or dynamic pages
  • Verify that user input is always placed in template data context, never in template code
Tools: tplmap Burp Suite SSTImap Custom payloads
CWE-94 CWE-1336

WSTG-INPV-19: SSRF

Advanced

Server-Side Request Forgery (SSRF) testing checks whether the application can be tricked into making HTTP requests to unintended destinations, particularly internal services. SSRF exploits server-side functionality that fetches URLs, imports data, or processes webhooks to access internal resources.

Why it matters: SSRF is a critical vulnerability in cloud environments because it can access cloud metadata services to steal IAM credentials, interact with internal services not exposed to the internet, and pivot through the internal network. It was elevated to the OWASP Top 10 in 2021 as A10.

What to Check

  • Test URL input parameters with internal IP addresses (127.0.0.1, 169.254.169.254, 10.x.x.x)
  • Check for cloud metadata endpoint access (AWS, GCP, Azure metadata services)
  • Test for SSRF through file import, URL preview, webhook, and PDF generation features
  • Try bypass techniques for SSRF filters (DNS rebinding, URL encoding, IPv6, redirects)
  • Test for blind SSRF using out-of-band callbacks to attacker-controlled servers
Tools: Burp Suite Collaborator SSRFmap Gopherus Custom payloads
CWE-918

Relevant Certifications

The following certifications cover input validation testing concepts:

CEHOSCPGPENSecurity+GWAPT

Frequently Asked Questions

What is the difference between input validation and output encoding?

Input validation checks that incoming data conforms to expected formats and rejects anything that does not match. Output encoding transforms data so it is safe for the specific context where it is rendered (HTML, SQL, JavaScript, etc.). Both are necessary: input validation reduces the attack surface, while output encoding prevents exploitation even if validation is bypassed. A defense-in-depth approach uses both.

Why is SQL injection still one of the most common web vulnerabilities?

SQL injection persists because many applications still construct SQL queries by concatenating user input rather than using parameterized queries. Legacy applications, custom ORM layers, and stored procedures with dynamic SQL all create opportunities for injection. Additionally, complex query logic and developer shortcuts under time pressure continue to introduce new injection points even in modern applications.

What is Server-Side Request Forgery (SSRF) and why has it become more important?

SSRF occurs when an attacker can make the server send requests to unintended destinations, typically internal services or cloud metadata endpoints. It has become more important with cloud adoption because SSRF can access cloud metadata services (like AWS IMDSv1 at 169.254.169.254) to steal credentials and pivot to other cloud resources. SSRF was added to the OWASP Top 10 in 2021 as A10.

CyberFolio

Mastering web security testing? Showcase your skills.

Build a free, shareable cybersecurity portfolio that highlights your certifications, projects, and skills.

Build Your Portfolio →

Related WSTG Categories

WSTG-INFO
Information Gathering WSTG-CONF
Configuration and Deployment Management WSTG-IDNT
Identity Management WSTG-ATHN
Authentication Testing
← Back to Home ← All WSTG Categories