Reflected cross-site scripting: What It Means and How to Fix It

A GET parameter was returned as executable script markup in the response.

Do this: Encode untrusted output for its exact HTML context. Unencoded input can become executable script in another visitor's browser. Open the page you need
PassNo reflected script injection was confirmed in the tested GET parameters.
HighAn injected script element was reproduced in the returned HTML.

The fix, in one snippet

Example to adapt Template auto-escaping
Render user input as text; never concatenate it into HTML, attributes, or script.

Illustrative values. Change the paths, hostnames and options to match your own site before using it.

The sections below explain what is tested, why it matters and the alternatives.

What we test

After ownership verification, Scan.now replaces each existing GET parameter with a unique script element and parses the returned HTML. It reports a failure only when that exact element survives as markup. It does not execute JavaScript, submit forms, or test stored or DOM-based XSS.

Why it matters

Reflected XSS lets an attacker place script in a crafted link. When a victim opens it, the script runs with the affected site's origin and can act as that user.

How to fix it

Use framework auto-escaping and context-specific output encoding. Do not concatenate request values into HTML, attributes, URLs, CSS, or JavaScript. Add a strict nonce- or hash-based Content Security Policy as defence in depth.

Where this fits

Reflected cross-site scripting is check 6 of 19 that the xss vulnerability scanner runs under page content and javascript, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.

Fix this one first

Above it in the same category sits Mixed content (HTTP resources on an HTTPS page) (high), where the HTTPS page loads scripts, styles, frames or media over plain HTTP. An attacker who has that does not need this, so it is the better use of the same hour.

What fixing this still leaves open

Reflected cross-site scripting closes one route in. Immediately below it: DOM XSS source and sink review, where inline client code contains both attacker-controlled DOM sources and dangerous rendering or execution sinks; Open redirect, where a redirect-like GET parameter accepted an external Scan.now URL; POST form without recognisable CSRF protection, where a POST form has no recognisable anti-CSRF field.

Found in the same scan

The xss vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Path traversal / local file inclusion, where a path-like parameter returned a known local operating-system file signature, and Session token exposed in URL, where a session-like token name appears in a discovered URL. A single run of xss vulnerability scanner answers all of them at once.

Prompt for an AI Hand this check to an assistant Sign in to copy it
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.

Finding: Reflected cross-site scripting (high severity)
Scanner check id: reflected-xss-active
17 more lines, including the evidence and the exact fix

The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.

Sign in with Google

Signing in is free and takes one click. We store your email address and nothing else.

References

  1. OWASP Cross Site Scripting Prevention Cheat Sheet