Overview
Cross-Site Scripting (XSS) is a class of vulnerability where an application allows attacker-controlled script to run in another user's browser. The first type to understand is reflected XSS, where the malicious input is echoed straight back in a response. This lesson covers reflected XSS conceptually and defensively.
Learning objectives
- Define XSS and the reflected variant.
- Explain how reflected XSS is delivered.
- Recognize the vulnerable pattern and its defense.
Core concept
XSS occurs when untrusted input is included in a page such that the browser executes it as script in the context of the vulnerable site. Reflected XSS is the variant where input from a request (e.g. a query parameter) is immediately reflected back in the response without safe handling, so a crafted request causes script to run in the victim's browser. It is typically delivered via a malicious link the victim clicks — the payload is not stored; it lives in the request.
How it works
An application takes input (say a search term) and includes it in the response page. If it inserts that input without output encoding, script contained in the input executes when the page renders. Because the payload rides in the request, an attacker crafts a link containing it and lures a victim to click; the victim's browser sends the request, the server reflects the payload, and the script runs as if it came from the trusted site — gaining access to that site's context (cookies not marked HttpOnly, DOM, actions on behalf of the user). The root cause is the same code/data boundary failure: untrusted data treated as code in HTML output.
Practical example
A search page displays "Results for: <your term>" by inserting the term directly into the HTML. If the term is reflected unencoded, input containing markup/script executes in the browser. An attacker sends a victim a link to the trusted site with such a term embedded; clicking it runs the script in the victim's session on that site. The fix is to output-encode the term for the HTML context so it is displayed as text, never executed (covered in the output-encoding lesson).
Cybersecurity relevance
Reflected XSS can lead to session theft (if cookies are script-accessible), performing actions as the victim, credential harvesting via fake forms, and more — all in the trusted site's context. It is common wherever request data is echoed into responses. Testers look for input reflected unencoded into pages; defenders apply context-appropriate output encoding and CSP. Reflected XSS also underscores why HttpOnly cookies and CSP (later lessons) matter as defense in depth.
Common mistakes
- Reflecting request input into HTML without output encoding.
- Assuming reflected XSS is low-risk because it needs a click — it still runs in the trusted context.
- Filtering specific tags instead of encoding for the output context.
Key takeaways
- XSS runs attacker-controlled script in a victim's browser in the trusted site's context; reflected XSS echoes request input back unsafely.
- It is typically delivered via a crafted link; the payload lives in the request, not storage.
- Root cause is unencoded untrusted data in HTML output; the fix is context-appropriate output encoding (plus CSP and HttpOnly cookies as defense in depth).
Check your understanding
- How is reflected XSS typically delivered to a victim?
- Why does script injected via reflected XSS run with the trusted site's privileges rather than the attacker's?