Overview
XSS comes in three types — reflected, stored, and DOM — and recognizing which you're hunting shapes the approach. This lesson covers the three XSS types in hunting.
Learning objectives
- Distinguish reflected, stored, and DOM XSS.
- Explain how to hunt each type.
- Connect type to source→sink and impact.
Core concept
The three XSS types (from the web-security XSS module):
- Reflected — input is immediately reflected back in a response (source→server sink in the same request); delivered via a crafted link.
- Stored — input is saved and later served to other users (source→storage→server sink); executes for anyone who views it (highest impact/reach).
- DOM — the unsafe source→sink flow happens entirely in client-side JavaScript (source→DOM sink), often invisible to server-side analysis.
Recognizing the type guides where to look (server response vs storage vs client-side code) and reflects the source→sink flow's location.
How it works
For reflected XSS, the researcher checks whether input in a request is reflected unencoded in the response (testing parameters/sources per-request). For stored XSS, they check whether input submitted to one place (e.g. a comment, profile field) is later displayed unencoded to other users — tracing storage to display sinks (higher impact, as it affects many users). For DOM XSS, they analyze client-side code for a source (e.g. URL fragment) flowing into a dangerous DOM sink without safe handling — since the flow is in the browser, server-response inspection alone misses it. Each type is confirmed with minimal, safe proof, per program rules.
Practical example
Hunting an in-scope app, the researcher finds: a search parameter reflected unencoded in the response (reflected XSS, delivered via a crafted link); a profile field that, when set, is displayed unencoded to other users (stored XSS — higher impact); and, in client-side code, a URL-fragment source flowing into an HTML-parsing DOM sink (DOM XSS). Recognizing each type guided where they looked (response, stored-then-displayed, client-side code) and how they assessed impact (stored being the broadest). Each was confirmed minimally and safely.
Cybersecurity relevance
Recognizing XSS types is essential to hunting them effectively: each type's source→sink flow is in a different place (same-response, stored-then-displayed, or client-side), so hunting reflected, stored, and DOM XSS requires different attention (per-request reflection, cross-user storage, client-side code analysis). Stored XSS is typically highest-impact (affects many users, including possibly admins), influencing severity. This maps directly to the web-security XSS/DOM-XSS lessons. Confirming with minimal, safe proof keeps testing responsible. Covering all three types ensures comprehensive XSS hunting.
Common mistakes
- Only hunting reflected XSS, missing stored (high-impact) and DOM XSS.
- Not analyzing client-side code for DOM XSS (invisible to server-response inspection).
- Underrating stored XSS impact (it affects many users, not just the submitter).
Key takeaways
- Reflected XSS reflects input in the same response (via a crafted link); stored XSS saves input and serves it to other users (highest reach/impact); DOM XSS's unsafe flow is entirely client-side.
- Each type's source→sink flow is in a different place, so hunting each requires different attention (per-request, cross-user storage, client-side code).
- Stored XSS is typically highest-impact (many users affected); cover all three types, confirming with minimal, safe proof (mapping to web-security XSS lessons).
Check your understanding
- How do reflected, stored, and DOM XSS differ in where their source→sink flow occurs?
- Why is stored XSS typically the highest-impact type?