Detecting Reflected XSS: What Your Security Scanner Should Check in 2026

1. How Reflected XSS Works

Reflected XSS follows a three-step pattern:

1. Injection — The attacker crafts a URL with a malicious payload in a query parameter, form field, or HTTP header.
2. Reflection — The server includes the payload in its response without proper encoding. The payload appears in the HTML body, an attribute value, or a JavaScript context.
3. Execution — The victim's browser parses the response and executes the injected script. The attacker can steal session cookies, redirect the user, or modify the page content.

The key distinction from stored XSS: reflected payloads are not persisted. They exist only in the request-response cycle. This means the attacker needs to trick the victim into clicking a crafted link — typically via phishing, social engineering, or embedding the link in a forum post.

A Simple Example

Consider a search page that reflects the query parameter:

GET /search?q=test HTTP/1.1

Response:
You searched for: test

If the application doesn't encode the q parameter:

GET /search?q= HTTP/1.1

Response:
You searched for: 

The browser executes the script tag. The attacker now has the victim's session cookie.

2. The 7 Payloads Every Scanner Should Test

Different payloads target different reflection contexts. A thorough scanner tests at least these seven variants per parameter:

Testing only payload #1 catches maybe 30% of reflected XSS. Testing all seven catches 80%+. The remaining 20% requires context-specific payloads (template injection, DOM-based XSS) that go beyond reflected testing.

3. Context-Aware Detection: Why It Matters

Not all reflections are equal. A scanner that reports every reflected parameter as "HIGH" severity generates noise that buries real findings. Context-aware detection classifies severity based on where the payload appears in the response:

How Context Detection Works

The scanner checks the response in order:

1. Is the raw payload present in the body? If yes, check if it's inside an attribute (regex match for =["']..payload..["']). Attribute context = MEDIUM. Otherwise = HIGH.
2. Is only the HTML-encoded version present? (e.g., <script> instead of <script>). If yes = LOW.
3. Neither version present? The parameter doesn't reflect this payload. No finding.

This three-tier classification means security teams can focus on HIGH findings first, investigate MEDIUM findings for exploitability, and track LOW findings as potential weaknesses without treating them as urgent.

4. How a Good Scanner Approaches XSS Testing

The scanning workflow for reflected XSS:

1. Parse the target URL — Extract all query parameters. Each parameter is a potential injection point.
2. For each parameter, for each payload — Replace the parameter value with the payload. Send the request. Analyze the response.
3. Classify the reflection — Apply context-aware severity (HIGH/MEDIUM/LOW/NONE).
4. Report the highest severity per parameter — If a parameter reflects multiple payloads, report the most severe one.

For a URL with 5 parameters and 7 payloads, that's 35 requests. This is why XSS scanning is inherently noisy — and why context-aware classification is essential to keep the signal-to-noise ratio manageable.

What Scanners Often Miss

• POST body parameters — Many scanners only test query string parameters. POST forms are equally vulnerable.
• HTTP headers — Referer, User-Agent, and custom headers can be reflected in error pages and logs.
• JSON API responses — If a JSON response is rendered as HTML (content-type mismatch), XSS payloads in JSON values can execute.
• DOM-based XSS — The payload never reaches the server. It's processed entirely in client-side JavaScript. Requires a headless browser to detect.

5. WAF Bypass Patterns That Still Work

Web Application Firewalls block known XSS patterns. But the bypass game is well-documented:

• Case variation — <ScRiPt>alert(1)</ScRiPt>. HTML is case-insensitive; many WAF rules are not.
• Event handler diversity — WAFs block onerror and onload but miss onfocus, onmouseover, ontoggle, and dozens of other event handlers.
• SVG and MathML — <svg> and <math> elements support event handlers and are often not in WAF blocklists.
• Encoding tricks — HTML entities (<script>), Unicode normalization, and double encoding can bypass pattern matching.
• Null bytes — <scr%00ipt> may bypass WAF string matching while the browser ignores the null byte.

The lesson: WAFs reduce the attack surface but don't eliminate XSS. Output encoding at the application level is the only reliable fix.

6. Fixing XSS: Context-Aware Output Encoding

The fix for reflected XSS is context-aware output encoding. The encoding must match the context where the data appears:

Framework-Level Protection

Modern frameworks provide automatic encoding — but only if you use them correctly:

• React — JSX auto-escapes by default. Danger: dangerouslySetInnerHTML bypasses this.
• Angular — Template binding auto-sanitizes. Danger: bypassSecurityTrustHtml().
• Django — Template auto-escaping on by default. Danger: |safe filter and mark_safe().
• Express/Node — No auto-encoding. You must use a template engine (EJS, Handlebars) or manually encode.

The pattern: every framework has an escape hatch. XSS happens when developers use the escape hatch without understanding the risk.

7. Content Security Policy as Defense in Depth

Content Security Policy (CSP) is the strongest defense-in-depth measure against XSS. A strict CSP prevents inline script execution even if XSS exists in the application.

Recommended CSP for XSS Mitigation

Content-Security-Policy: 
  default-src 'self';
  script-src 'nonce-{random}' 'strict-dynamic';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data:;
  object-src 'none';
  base-uri 'self';

Key directives:

• script-src 'nonce-{random}' — Only scripts with a matching nonce attribute execute. Injected scripts won't have the nonce.
• 'strict-dynamic' — Scripts loaded by trusted scripts are also trusted. Simplifies CSP for applications that dynamically load modules.
• object-src 'none' — Blocks Flash and Java applets, which can be used for XSS.
• base-uri 'self' — Prevents base-tag hijacking, a CSP bypass technique.

CSP is not a replacement for output encoding. It's a safety net. If your encoding fails, CSP catches the fall. If your CSP has gaps, encoding is still there. Defense in depth.

8. Scanner Checklist

Bottom Line

Reflected XSS detection is a solved problem — in theory. In practice, most scanners test too few payloads, don't classify by context, and miss non-query-string injection points. A good scanner tests 7+ payload variants per parameter, classifies findings by reflection context (HIGH/MEDIUM/LOW), and covers POST bodies and headers in addition to query strings.

On the fix side: context-aware output encoding is the primary defense, CSP is the safety net, and WAFs are the speed bump. All three together give you defense in depth against the vulnerability that's been in the OWASP Top 10 since the list was created.

This is the second article in our injection detection series. First: SQL Injection Detection. Next: Server-Side Request Forgery (SSRF) — coming when the detection tooling is ready.