XSS Testing

Written authorization must be obtained before XSS testing begins. XSS testing can have real consequences if a payload redirects users, modifies visible page content, executes actions in their browser session, or transmits information to an external system.

Before testing, clearly define the scope of the assessment, including:

Which applications, hosts, and environments are in scope
Which pages, endpoints, and input points may be tested
Whether testing production systems is permitted
Which testing techniques are allowed or prohibited
Any restrictions on accessing or handling user data
Testing windows and rate limits, where applicable

Testing should remain strictly within the authorized scope, and payloads should be designed to demonstrate the vulnerability with minimal impact.

Identify all in-scope input points including form fields, URL parameters, HTTP headers, cookies, and other user-controlled values. Begin by placing a distinctive, non-malicious marker into each input and determine whether the value is reflected immediately, persisted for later retrieval, or processed only in the browser.

For each reflection, inspect the raw HTTP response and, where relevant, the resulting DOM to determine where the input is inserted and how it is interpreted. Use Lesson 3's rendering context framework to classify the location, such as HTML text, HTML attribute, JavaScript, CSS, URL, or DOM context.

Once the context is established, select a minimal, context-appropriate proof-of-concept that is safe for the authorized testing environment. The objective is to demonstrate that the application treats attacker-controlled input as executable content not merely that the input is reflected while avoiding actions that modify data, redirect users, or exfiltrate information.

Elements/Inspector: Shows the actual DOM after the browser has parsed and modified the HTML. This can differ from the original/raw HTML because browsers may automatically correct malformed markup.

Console: Shows JavaScript errors and warnings. These can reveal that injected content reached a JavaScript execution context but failed because of syntax or context issues.

Network: Shows the HTTP requests sent by the browser and the responses received from the server. This is often more informative than the rendered page because it lets you determine exactly what data was transmitted and returned.

Once a payload executes, trace the execution back to its exact source: identify which input parameter carried the value, which endpoint processed it, where the value was rendered, and whether the reflection was immediate or resulted from previously stored data.

Avoid vague findings such as “XSS exists somewhere on this page.” A useful finding should identify the precise data flow—for example: “The comment parameter on this endpoint is reflected into an HTML attribute without appropriate output encoding, allowing attacker-controlled content to be interpreted as markup.”