Reflected Cross-Site Scripting (XSS)
User input is echoed into pages unescaped, so crafted links run attacker JavaScript in your visitors' browsers.
What is Reflected Cross-Site Scripting (XSS)?
Reflected XSS occurs when input from the request — a search term, an error message, a URL parameter — is written into the HTML response without proper encoding. The attacker crafts a link containing the payload (your-site.com/?q=<script>...) and delivers it to a victim by email, chat, or a malicious page. When the victim clicks, the payload executes in the context of YOUR origin: it can read the page, steal non-HttpOnly cookies, make authenticated requests, log keystrokes, and rewrite what the victim sees. It is called "reflected" because the payload bounces off the server into the response, rather than being stored.
Why It Matters to Your Business
A single reflected XSS lets an attacker act as any visitor who clicks their link — including administrators. Session theft leads to account takeover; keylogging captures passwords typed on your pages; and content injected under your domain and certificate is trusted by users, enabling highly credible phishing. XSS findings are taken seriously in bug bounties and procurement security reviews alike, and shipping a fix is far cheaper than explaining an incident.
How to Fix It
1. Encode output by context — the single most important rule. HTML body needs different encoding than attributes, JS strings, URLs, and CSS:
Laravel Blade ({{ }} auto-escapes — that is the fix, use it):
{{ $search }} SAFE
{!! $search !!} RAW - only for trusted HTML you generated yourself
JavaScript context (put data in a data-attribute or JSON, not inline):
<div data-query="{{ $search }}"></div>
const q = el.dataset.query;
Node/React (JSX auto-escapes), Angular ({{ }} auto-escapes) — the dangerous APIs are the escape hatches (dangerouslySetInnerHTML, [innerHTML], v-html, bypassSecurityTrust).
2. Set cookies HttpOnly and SameSite to blunt payload impact.
3. Add a Content-Security-Policy as a second layer (script-src 'self') — it mitigates what encoding misses.
4. Sanitize rich text server-side with an allowlist sanitizer (HTML Purifier / DOMPurify) — never regex-strip tags.
Frequently Asked Questions
What is the difference between reflected and stored XSS?
Reflected XSS lives in a crafted link — the payload rides in the URL and only runs for people who receive that link. Stored XSS is saved on the server (a profile field, a comment) and runs for every visitor of that page. Same impact, different delivery.
How does an attacker exploit XSS on my site?
They send a victim a link containing the payload. When clicked, the script runs under your domain: it steals cookies that are not HttpOnly, performs actions as the logged-in user, captures keystrokes, or displays a fake login form that users trust because the address bar shows your site.
Does a Content-Security-Policy fix XSS by itself?
No. CSP is a powerful second layer that blocks many payloads, but encoding at the output layer is the primary fix. Some CSP configurations can also be bypassed; defense in depth means both.
Technical Classification
| OWASP Category | A03:2021 — Injection |
| CWE ID | CWE-79: Improper Neutralization of Input During Web Page Generation |
| Detected By | xss_advanced, dalfox_xss, zap scanner(s) |
| Severity Level | high |
How 2MNY Security Can Help
Check if your website has this vulnerability
Our xss_advanced, dalfox_xss, zap scanner checks for this issue automatically.
Scan My Website FreeRelated Vulnerabilities
Open Redirect Vulnerability
The site has an open redirect — a parameter that redirects to any URL, allowing phishing campaigns that appear to come from your domain.
Dangerous HTTP Methods Enabled
The server allows dangerous HTTP methods (PUT, DELETE, TRACE, CONNECT, WebDAV) that can be abused for file upload, deletion, or cross-site tracing.
SQL Injection (Reflected) Vulnerability
Unvalidated user input flows into database queries, letting attackers read your data or take over the server.
DOM-Based Cross-Site Scripting (XSS)
Client-side JavaScript writes untrusted data into the DOM, executing attacker scripts without the server ever seeing the payload.