Cybersecurity glossary
What is Reflected XSS?
Learn what reflected XSS is, how malicious input in a request is echoed into a response as active content, how attackers deliver payloads via links, and how encoding and CSP stop it.
Definition
Reflected XSS is a cross-site scripting vulnerability in which attacker-controlled input from a request is immediately included in the HTTP response without proper neutralization, so a victim who opens a crafted link executes attacker script in the trusted site’s origin.
Why reflected XSS matters
Reflected XSS is often the first XSS type people learn—and it remains common because applications constantly echo user input for convenience: search terms, error details, tracking parameters, and “you searched for…” banners.
Reflected XSS is non-persistent on the server, but that does not make it low impact. A single crafted link can run attacker JavaScript as the trusted site for whoever opens it, enabling session abuse, credential phishing on-domain, and malware delivery.
How reflected XSS works
Find a reflection point
Identify parameters or headers that appear in HTML responses.
Inject active content
Supply markup or script that breaks out of the surrounding HTML context.
Confirm execution
The response includes the payload in a way the browser executes.
Weaponize a URL
Package the payload into a link or request the victim will trigger.
Deliver socially
Phishing, ads, or compromised sites send victims to the crafted URL.
Achieve objectives
Act as the user, steal accessible data, or pivot to further attacks.
Reflected vs stored vs DOM XSS
| Type | Persistence | Typical delivery |
|---|---|---|
| Reflected | Not stored server-side | Malicious link / crafted request |
| Stored | Saved and shown later | Victim visits a normal infected page |
| DOM-based | Client-side data flow | URL fragment or client-only state |
Common reflection sinks
Search and filters
Query strings rendered into result headers without encoding.
Error pages
Exception messages that include raw user input.
Tracking parameters
utm_ or debug values echoed into analytics snippets unsafely.
Attribute contexts
Values placed into HTML attributes or JavaScript string literals incorrectly.
Prevention checklist
- Encode all untrusted data for the correct output context (HTML, attribute, JS, URL).
- Use templating frameworks that auto-escape by default; avoid raw HTML helpers.
- Validate and constrain inputs where a strict format is expected.
- Deploy a strict CSP with nonces/hashes as defense in depth.
- Set cookie flags (HttpOnly, Secure, SameSite) to reduce some follow-on impact.
- Test every reflection point, including authenticated and error responses.
- Do not rely on blacklist filters for `<script>` alone.
- Review mobile webviews and alternate content types that may reflect input.
The practical takeaway
Reflected XSS echoes attacker input from a request into a response as executable content. Delivery is often a malicious link; impact is full script privilege in the trusted origin for the victim.
Encode correctly, use safe defaults, add CSP, and treat every “echo this parameter” feature as a potential XSS sink.
Related security terms
Cross-Site Scripting (XSS)
The broader XSS category that includes reflected, stored, and DOM-based types.
Stored XSS
XSS that persists in the application and later hits other users.
DOM-Based XSS
Client-side XSS that may not require server reflection into HTML.
Content Security Policy (CSP)
A defense-in-depth control that can reduce reflected XSS impact.
Cross-Site Scripting (XSS)
Deep dive on XSS exploitation beyond this glossary definition.
Frequently asked questions
What is reflected XSS in simple terms?
Reflected XSS happens when a website takes something from the URL or form and shows it back on the page unsafely. An attacker sends a victim a link that includes malicious script, and the site reflects it into the victim’s browser.
How is reflected XSS different from stored XSS?
Reflected XSS is delivered in the same request/response cycle and is usually not saved. Stored XSS is saved on the server and affects users who later view the poisoned content.
Do victims have to click a link?
Often yes—email, chat, or ads deliver the crafted URL. Some reflected bugs can also be triggered through other request channels the victim’s browser will make.
Can reflected XSS steal sessions?
Yes, if cookies are accessible to script or if the attacker can perform actions in the user’s session. HttpOnly cookies reduce simple cookie theft but do not stop all XSS impact.
Does a WAF stop reflected XSS?
It may block known payloads, but encoding and safe templating are the real fixes. Obfuscation routinely bypasses filters.
Where do reflected XSS bugs commonly appear?
Search results, error messages, redirect pages, analytics debug parameters, and any feature that echoes query values into HTML.
How do you prevent reflected XSS?
Context-aware output encoding, safe frameworks, avoiding dangerous sinks, input validation where appropriate, and a strong Content Security Policy.
References
Explore authoritative guidance and frameworks related to reflected xss.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.