DOM XSS

What Is DOM XSS?

DOM-based XSS is the cross-site scripting your server never sees. The payload rides in the URL fragment, document.referrer or a postMessage body, and client-side JavaScript writes it into innerHTML . Server-side filters and web application firewalls are blind to all of it. You'll pack an img onerror payload into a share link for a note viewer, open it yourself, trace the flow from source to sink, and fix it with textContent so the browser builds a text node instead of parsing markup.

What You'll Learn in DOM XSS

• Recognize the source-to-sink pattern: an attacker-controlled DOM source (location.hash, document.referrer, postMessage) feeding a dangerous DOM sink (innerHTML, eval, document.write)
• Explain why the URL hash never reaches the server and why WAF / server-side filters are blind to DOM XSS
• Apply the right primary fix: swap the dangerous sink (innerHTML) for a safe one (textContent), not server-side filtering or input rewriting
• Distinguish DOM XSS from Reflected and Stored XSS by where the payload flows and where the fix has to land
• Audit a codebase for adjacent source-to-sink pipes once one bug surfaces

DOM XSS — Training Steps

1. Open the note-sharing tool

   Today Bob is targeting Tideline Federal, whose staff pass around quick notes through an internal sharing tool. You write a note, the tool hands you a link, and anyone who opens the link reads the note in their browser. Bob opens the composer to see how a note becomes a link.

2. Share a normal note

   First, Bob shares an ordinary note to see how the tool builds a link. Whatever he writes gets packed into the link itself.

3. The note rides in the link

   There's the share link. The whole note sits inside it, in the part after the # . When someone opens the link, the viewer reads that fragment and renders it. Nothing about the note ever reaches Tideline's server.

4. Craft a test payload

   The viewer drops whatever the note contains into the page as HTML. So Bob writes a note that is not really a note: an image tag whose source cannot load, carrying an onerror handler. When the image fails, the handler runs, and any code it holds executes in the browser of whoever opens the link. He starts with the simplest possible proof, a plain alert(1) , just to confirm his code runs at all.

5. Test the payload

   Before he weaponizes anything, Bob previews his own link to check that the payload fires. Preview opens the note exactly the way a recipient would see it. The moment the viewer loads it, the alert pops. His code runs in the browser, exactly as planned.

6. Weaponize it

   The proof works, so now Bob makes it dangerous. He goes back to the composer and swaps the harmless alert for a line that reads the visitor's session cookie, the token that keeps them signed in. A real payload would ship that cookie to his own server without a sound. Here it pops the stolen value into view so you can see exactly what it captures.

7. Send the link to a victim

   Bob emails the weaponized link to Alice, a Tideline engineer who opens shared notes all day. It is dressed up as a note shared ahead of her morning review, so she has no reason to hesitate.

8. A shared note arrives

   Bob's email is on its way. You own the note-sharing tool's viewer code, and a shared note lands in your inbox right before your 10:00 review. Open it, then open the note.

9. Open the shared note

   Nothing looks off, so you open the note the way you open dozens of others.

10. The note steals your session

    The instant the note loaded, this popup fired in your browser, and it is showing your own session cookie, the token that keeps you signed in. You clicked nothing and typed nothing. The shared note carried a script, and it just read your session and could have shipped it straight to an attacker. That is a full account takeover from opening one link.