Reflected Cross-Site Scripting
Summary
Reflected XSS lets an attacker inject a script through a request parameter that's echoed back unescaped, running in the victim's browser via a crafted link. Reflected XSS reports cluster around four reflection contexts:
- HTML body - payload reflected raw inside <body>/<div> with no encoding, classic
<svg/onload=alert(1)> - HTML attribute - value reflected inside an attribute, broken with
"><payload> - JavaScript string - value reflected inside a JS variable, broken with
';alert(1);// - URL/href - value reflected inside an anchor href or location.replace, exploited with
javascript:alert(1)(or carriage-return tricksja\r\nvascript:). The big bypass tricks: WAF evasion via newline tricks (\r\n in href), base64-encoded location.hash, mixed-case tags, double-URL-encoding, SVG with onload=, polyglots, encoded brackets, and usingdocument.locationmutation. Asset patterns: search forms (q, keyword, query, search), error pages reflecting path/method, hidden parameters discovered via parameter mining, OAuth callback echo, login forms reflecting username on error.
Top Affected Components / Targets
Search endpoints reflecting query string in resultsError pages reflecting path / method / parameter valuesLogin forms reflecting username on failed loginFilter / sort / pagination parameters in listingsHidden parameters mined via param-miner / ArjunOAuth callback / SSO endpoints echoing state or codeURL-aware features: redirect param, return_to, next, callbackLegacy ColdFusion / ASP / PHP search pagesWordPress-based sites with custom plugins reflecting query argsDrupal node.js search reflecting entire path
Common Attack Vectors
Inject<script>alert(1)</script>into every URL parameter and observe reflectionInject<svg/onload=alert(1)>to bypass naive <script> filtersInject"><img src=x onerror=alert(1)>to break out of attribute contextInject';alert(1);//to break out of JS string contextInjectjavascript:alert(1)into href / src / location parametersUseja\r\nvascript:alert(1)to bypass URL-scheme allowlist (newline trick)Use double URL encoding%253Cscript%253E``Use mixed case<ScRipT>, exotic tags<details ontoggle=>,<marquee onstart=>``Inject into path:/page/<svg/onload=alert(1)>for path-reflection bugsSubmit hidden parameters discovered through wordlist / param-miner
Common Payloads
<svg/onload=alert(1)><svg onload=alert(1)>"><svg/onload=alert(1)>"><img src=x onerror=alert(document.domain)><img src=x onerror=alert(1)>javascript:alert(1)ja%0d%0avascript:alert(1)';alert(1);//</script><svg/onload=alert(1)><a+href="ja%0a%0Dvascript:alert(document.domain)">Click</a>
Detection Strategy
Tools like Dalfox handle the canonical case of reflected XSS well on their own, but disclosed reports consistently point to two gaps that a straightforward parameter scan misses: hidden parameters and path reflection. A parameter-mining pass, run against every URL with at least one parameter using a wordlist of commonly hidden names (q, query, search, keyword, term, name, page, ref, callback, return, next, redirect, debug, cmd, and similar), surfaces candidates that a standard scan never tries; anything that changes the response length or status is worth testing further. Path reflection is worth checking separately: replacing the last path segment with a unique token, and again with a payload like <svg/onload>, and watching whether either comes back unencoded, catches bugs that live outside the query string entirely. Header reflection is another common gap: injecting a unique token into headers that are often echoed back, such as Referer, User-Agent, X-Forwarded-Host, Host, Origin, and Accept-Language, and checking the response body for it. Once reflection is confirmed, classifying exactly where it lands (HTML body, an attribute, a JavaScript string, or a URL) makes it possible to pick the right breakout payload for that specific context, which cuts down on false positives from reflections that are actually encoded safely. When an initial payload gets blocked but reflection still exists, a bypass library covering SVG/onload, exotic tags like marquee/onstart or details/ontoggle, mixed case, scheme-newline tricks, and double URL encoding often gets past naive filters. Confidence rises with each successful bypass variant that lands.
Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.
False-Positive Notes
- Reflection alone isn't XSS - the response context must allow code execution.
- Many sites encode <, >, " but still reflect single quotes inside JS strings; the context-aware payload picker handles this.
- WAF-block responses often look like 200 OK with a generic page - ensure the response body actually contains the injected token before flagging.
- CSP can prevent execution even when reflection exists; CSP-blocked findings should be downgraded to 'CSP-mitigated XSS' (medium) rather than 'XSS' (high).
How to Test
Manual Testing Methodology
Here is a systematic approach to identifying Reflected Cross-Site Scripting vulnerabilities in a target application.
Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.
Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.
Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Reflected Cross-Site Scripting specifically, inject a unique, easily-searchable marker string into every parameter first to map which ones reflect at all, then follow up on the reflecting ones with context-appropriate breakout payloads — "><svg/onload= for an HTML/attribute context, ';alert(1);// for a JavaScript string context, javascript: for a URL context.
Compare the response against your baseline, looking specifically for whether the marker or payload comes back unencoded and in an executable position — a reflected < that renders as < in the page source is evidence of correct encoding, not a finding, no matter how the marker itself looks in a diff.
Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Reflected Cross-Site Scripting, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.
Real-World Impact
Real-World Impact
Cross-site scripting lets attackers execute arbitrary JavaScript in a victim's browser, effectively hijacking their authenticated session. This leads to session token theft, credential harvesting through fake login forms, cryptocurrency mining in the browser, defacement, and in social platforms, worm-like propagation from one infected profile to the next.
Stored XSS is particularly severe because it can affect every user who views the poisoned content, meaning a single injection point can compromise thousands of sessions at once. It's also frequently chained with CSRF to perform administrative actions or exfiltrate internal data once an attacker has script execution in an authenticated context.
XSS remains one of the most commonly reported vulnerability classes across web applications of every size, which is part of why it still shows up so often in disclosed reports despite being well understood.
Prevention & Remediation
Prevention and Secure Coding
Preventing Reflected Cross-Site Scripting takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.
Context-aware output encoding. Encode output for the exact context it lands in — HTML body, HTML attribute, JavaScript string, or URL — at render time, not once globally; the same value needs different encoding depending on where it's placed.
Auto-escaping frameworks. Modern templating and component frameworks (React, Vue, Angular) escape output by default — the actual risk concentrates in the explicit escape hatches (dangerouslySetInnerHTML, v-html, [innerHTML]) that bypass that protection, so audit those call sites specifically.
Content-Security-Policy. A script-src CSP built on nonces or hashes (not unsafe-inline) stops injected inline scripts from executing even if a payload gets through the encoding layer.
Allowlist sanitization for rich text. Where users are meant to submit formatted content, sanitize it server-side with an allowlist HTML sanitizer, not a denylist regex — denylists are reliably bypassable.
Cookie flags as a backstop. HttpOnly on session cookies limits the blast radius of a successful injection by keeping the token out of reach of document.cookie even if script execution succeeds.
Source reports
A sample of the disclosed HackerOne reports this playbook was synthesized from.