What is Reflected XSS and How Does It Execute Only Within a Browser Session?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Reflected XSS (also called non - persistent or Type - I XSS) runs only during a single request/response cycle.
• The malicious script is delivered back to the victim’s browser and is not saved on the server.
• Mitigation requires proper input validation, output encoding, and Content - Security - Policy headers.

What is reflected XSS and why is it called non - persistent?

Reflected XSS is a cross - site scripting flaw where user - supplied data is included in the HTTP response without proper sanitisation, causing the payload to execute in the victim’s browser during that request. It is called non - persistent because the payload is never stored on the server; it exists only for the duration of the current session.

How does reflected XSS execute within the browser session without being saved?

The attacker crafts a URL containing a malicious script as a query parameter or form field. When the victim clicks the link, the vulnerable server reads the parameter and injects it directly into the HTML response. The browser parses the response and runs the script immediately, but because the server does not persist the input, there is no record of the payload after the response is sent.

Which parts of a web application are most prone to reflected XSS?

• Search result pages that echo the search term.
• Error pages that display the requested URL.
• Login or feedback forms that return the submitted value in a message.
• Any endpoint that reflects request parameters into the HTML without encoding.

What are concrete steps to prevent reflected XSS?

1. Validate input - reject unexpected characters or enforce a whitelist of allowed values.
2. Encode output - use context - aware encoding (HTML entity encoding for HTML bodies, URL encoding for query strings, JavaScript encoding for inline scripts).
3. Set a Content - Security - Policy - include script-src 'self' and avoid unsafe-inline to block injected scripts.
4. Use security libraries - frameworks like OWASP Java Encoder, Ruby on Rails html_escape, or Express helmet provide built - in protections.
5. Test with a scanner - run a free Decloak scan; its core Layer 4 JavaScript CVE scanner will flag unsafe eval() and innerHTML patterns, while Layer 1 HTTP/TLS checks ensure secure headers like CSP are present.

How can you verify that a reflected XSS issue is fixed?

• Re - run the Decloak free scan on the affected URL; the report will show a clean result for the JavaScript patterns that trigger reflected XSS.
• Manually test by submitting a benign payload (e.g., <script>alert('test')</script>) and confirming it is not executed.
• Check the response headers for a CSP header that disallows inline scripts.

When should you consider active testing for reflected XSS?

If the free scan flags a potential reflected XSS but you need confirmation, upgrade to a paid Decloak plan and enable Active Security Testing. The active layer will safely probe the parameter with a harmless payload and report whether execution occurs, without exploiting the site beyond the consented test.

What are the risks of ignoring reflected XSS?

• Session hijacking via stolen cookies.
• Credential theft through phishing - style prompts.
• Drive - by malware installation.
• Reputation damage if attackers use the flaw for defacement.

Where can I learn more about XSS categories?

The OWASP XSS Cheat Sheet provides a detailed breakdown of reflected, stored, and DOM - based XSS, along with mitigation techniques. Decloak’s blog posts such as Every Report Now Includes an Explicit OWASP Top 10:2025 Coverage Checklist also map findings to the latest OWASP standards.