Back to scan results
Check 26 of 45

Cross-Site Scripting (XSS) Detection

We place unique, non-executing HTML markers in common public GET parameters and compare each response with a clean baseline. A marker returned as raw markup indicates that untrusted input may reach an HTML response without contextual output encoding.

What this check probes

The scanner tests the public HTTPS page with four common parameter names: q, search, query, and name. It sends an inert custom HTML element and a quote-boundary variation, then checks whether the exact value appears unencoded in an HTML response.

The probes contain no JavaScript, event handlers, external resources, or executable URLs. Properly HTML-encoded values such as <pciscan-xss-probe> are not reported as vulnerable. New HTTP 5xx responses are warnings, while rate-limited or WAF-blocked requests are counted but not treated as proof of a vulnerability.

This is a focused reflection check. It does not execute a browser payload and cannot test stored XSS, DOM-based XSS, authenticated screens, POST bodies, API inputs, or pages that are not linked from the public entry point.

Why this matters for PCI DSS

XSS can let an attacker run code in a customer's browser, steal session data, alter payment forms, or redirect cardholder data. PCI DSS secure-development requirements require public-facing applications to be protected from common software attacks, including injection into browser-rendered output.

A pass means only that these limited public probes were not reflected as raw HTML. It is not proof that every input and output context is safe; authenticated application testing and code review are still needed.

How to fix it

Encode at the output boundary for the exact context. In ASP.NET Web Forms, use encoded data-binding expressions or HttpUtility.HtmlEncode for HTML text:

<%: Request.QueryString["q"] %>

// Or in server-side code:
safeOutput.Text = HttpUtility.HtmlEncode(untrustedValue);

For client-side rendering, assign untrusted text with textContent instead of building markup with innerHTML. Use dedicated encoders for HTML attributes, URLs, JavaScript, and CSS because each context has different escaping rules.

Validate inputs against the format the application expects, use a well-maintained HTML sanitizer only when users are intentionally allowed to submit markup, and deploy a restrictive Content Security Policy as defense in depth. CSP does not replace output encoding.

Fixed it? Re-run the scan to confirm.

Run scan again