Overview
XSS occurs when input reaches a dangerous sink — an output context where data can execute as script. This lesson covers sinks in XSS hunting.
Learning objectives
- Define sinks in the XSS context.
- Identify server-side and client-side sinks.
- Connect source→sink analysis to finding XSS.
Core concept
A sink is a point where data is output or used in a way that could execute as script if unsafe. Server-side, the sink is where input is reflected into or stored in HTML output without proper encoding (reflected/stored XSS). Client-side, sinks are DOM APIs that interpret data as HTML or code (DOM XSS). XSS is fundamentally a source→sink problem: data flows from an input source to a sink; if it reaches a sink without safe handling (encoding), it can execute. Hunting XSS means tracing sources to sinks and checking whether the data is safely handled in between.
How it works
The researcher traces data from each input source to where it ends up — the sink. For server-side XSS, the sink is HTML output reflecting or displaying the input; the researcher checks whether it is output-encoded for that context (unencoded reflection/display is the flaw). For DOM XSS, the researcher analyzes client-side code (from the fingerprinting/endpoint work) to find where a source flows into a dangerous DOM sink (one that parses HTML or executes code) without safe handling. The source→sink trace — and whether safe encoding occurs along the way — is what reveals XSS. Testing uses safe, minimal probes (not weaponized payloads) to confirm whether data reaches a sink unsafely.
Practical example
Tracing a search parameter (source), the researcher finds it is reflected into the HTML response (a server-side sink). Checking whether it's output-encoded, they observe it appears unencoded — indicating potential reflected XSS. Separately, analyzing client-side code, they find a URL-fragment source flowing into a DOM sink that parses HTML without safe handling — potential DOM XSS. In both, the source→sink trace plus the lack of safe encoding reveals the flaw, which they confirm with a minimal, safe proof (per program rules), not a weaponized payload.
Cybersecurity relevance
The source→sink model is the core of XSS hunting: XSS exists precisely where an input source reaches a dangerous sink without safe handling. Identifying sinks — server-side (unencoded HTML output) and client-side (dangerous DOM APIs) — and tracing sources to them is how researchers find XSS systematically (from the web-security XSS/DOM-XSS lessons). It mirrors how the vulnerability actually arises. For defenders, it reinforces safe handling at every sink (output encoding, safe DOM APIs). Confirming reach with minimal, safe proof (no weaponized payloads) keeps testing responsible and within program rules.
Common mistakes
- Looking for sources without tracing them to sinks (or vice versa) — XSS is the source→sink flow.
- Overlooking client-side (DOM) sinks by only checking server responses.
- Using weaponized payloads instead of minimal, safe confirmation.
Key takeaways
- A sink is where data is output/used such that it could execute as script: server-side (unencoded HTML output) or client-side (dangerous DOM APIs).
- XSS is a source→sink problem — trace input from source to sink and check for safe handling (encoding) in between; a sink reached unsafely is the flaw.
- The source→sink model is the core of systematic XSS hunting (server-side and DOM); confirm with minimal, safe proof, not weaponized payloads.
Check your understanding
- What is a "sink" in XSS, and how do server-side and client-side (DOM) sinks differ?
- Why is XSS best understood and hunted as a source→sink data flow?