← Back to sandbox
Security - Client-Side Injection Intermediate 5 possible tests

DOM-Based XSS

A card preview feature reads a name from the URL hash and writes it to the page with innerHTML. The server never sees the payload - the vulnerability exists entirely in the browser. Find the inputs that cause JavaScript to execute, and identify which payloads the partial sanitization catches and which it misses.

What is DOM-Based XSS?

DOM-based XSS happens entirely in the browser. The server returns a safe page, but client-side JavaScript reads from an attacker-controlled source - such as location.hash - and writes it to the DOM using a sink like innerHTML. Because the payload never reaches the server, server-side sanitization offers no protection. The fix is to use safe sinks like textContent instead of innerHTML, or to apply client-side sanitization with a library like DOMPurify before writing to the DOM.

What is hidden here

True Negative Alice Johnson - plain text in the URL hash renders correctly with no code execution
True Positive <script>alert(1)</script> - script tag stripped by the partial sanitization regex before innerHTML assignment
Bug Found <img src=x onerror=alert(1)> - img onerror fires when the browser fails to load the invalid src, executing JavaScript
Bug Found <svg/onload=alert(1)> - SVG onload executes synchronously when the element is inserted via innerHTML
Bug Found <img src=x onerror=alert(document.domain)> - shows the attacker can access origin context and session data

Card Preview - Vulnerable to DOM XSS

This feature reads the URL hash and renders it into the card name with innerHTML. A partial sanitization strips <script> tags but leaves event-handler attributes on other elements untouched.

✗ Renders via innerHTML - no event-handler sanitization
LIVE PREVIEW
Your Name Here
Software Engineer
qa-sandbox.example.com
Quick tests
/qa-sandbox/dom-xss#
innerHTML assigned to #card-name
(nothing rendered yet)

  • Type Alice Johnson and click Preview Card - plain text renders safely in the card with no code execution (true negative)
  • Try <script>alert(1)</script> - the partial sanitization regex removes the script tag before innerHTML runs; browsers also block inline scripts injected via innerHTML by spec (true positive)
  • Try <img src=x onerror=alert(1)> - the img tag passes sanitization, the browser attempts to load the invalid src, fails, and fires onerror which executes the handler (bug found)
  • Try <svg/onload=alert(1)> - SVG onload fires synchronously when the element is inserted; no image load is required, execution is immediate (bug found)
  • Try <img src=x onerror=alert(document.domain)> - the handler runs in the page origin context; an attacker can read cookies, make authenticated requests, or exfiltrate data (bug found)
  • Notice the URL hash updates on every preview - in a real attack the victim receives a crafted link and clicks it; the malicious payload runs in their browser under the site's origin