Dom Based XSS FAQ & Answers

DOM-based XSS (CWE-79): Client-side vulnerability where attacker-controlled data flows from JavaScript source to dangerous sink without server involvement - payload executes purely in browser. Key difference: Payload NEVER sent to server (not in HTTP request/response), attack happens entirely in client-side JavaScript DOM manipulation, server logs won't show attack. XSS types comparison: (1) Reflected XSS - payload in URL → server reflects in response → browser executes (server-side), (2) Stored XSS - payload stored in database → server serves to users → browser executes (server-side), (3) DOM-based XSS - payload in URL fragment (#) or postMessage → client-side JavaScript reads and executes → server never sees it. Example: URL fragment https://example.com/page# read by JavaScript location.hash, then written to innerHTML - XSS executes without server involvement.

Dangerous sources (attacker-controlled): location.href, location.search, location.hash, document.URL, document.referrer, document.cookie, window.name, postMessage events, localStorage/sessionStorage. Dangerous sinks (execute code): eval(source), setTimeout(source), setInterval(source), Function(source), innerHTML = source, outerHTML = source, document.write(source), element.setAttribute('onclick', source), element.insertAdjacentHTML(source). Example attack: URL: https://example.com/page#. JavaScript: var hash = location.hash.slice(1); document.getElementById('output').innerHTML = hash; → XSS executes. Flow: attacker controls location.hash (source) → flows to innerHTML (sink) → code execution. Critical: ANY flow from source to sink without sanitization is vulnerable.

Safe methods to prevent DOM-based XSS: (1) Use textContent instead of innerHTML (no HTML parsing, text only, no execution): element.textContent = userInput; - completely safe. (2) Use innerText instead of innerHTML (respects CSS display, still no execution). (3) Use createElement + appendChild (programmatic DOM manipulation, no parsing): const div = document.createElement('div'); div.textContent = userInput; parent.appendChild(div);. (4) Use DOMPurify library for sanitizing HTML before innerHTML: element.innerHTML = DOMPurify.sanitize(userInput); - removes dangerous tags/attributes. (5) Avoid dangerous sinks: NEVER use eval(), setTimeout(string), Function(string), document.write(), setAttribute('onclick', ...) with user input. (6) Context-specific encoding: HTML context use DOMPurify, JavaScript context use JSON.stringify() then parse, URL context use encodeURIComponent(). Rule: if you must use innerHTML, sanitize with DOMPurify first. Otherwise use textContent.

Framework DOM-based XSS protections: (1) React - JSX auto-escapes by default (safe), dangerouslySetInnerHTML bypasses protection (only use with DOMPurify: <div dangerouslySetInnerHTML={{__html: DOMPurify.sanitize(userInput)}} />). (2) Vue - template interpolation {{}} auto-escapes (safe), v-html directive renders raw HTML (requires sanitization: <div v-html="DOMPurify.sanitize(userInput)"></div>). (3) Angular - built-in sanitizer automatically sanitizes innerHTML/[innerHTML] bindings, bypassSecurityTrustHtml() disables sanitization (avoid unless absolutely necessary with DOMPurify). (4) Svelte - template expressions auto-escape, {@html} tag renders raw HTML (sanitize first). Content Security Policy (CSP): script-src 'nonce-random123' blocks inline event handlers (onclick, onerror), unsafe-inline must NOT be used (defeats CSP), strict-dynamic for modern browsers. Rule: frameworks protect templates, but raw DOM manipulation (innerHTML, eval) still vulnerable.

Testing for DOM-based XSS: (1) Manual testing - inject payloads in URL fragments (#), query parameters (?name=), postMessage events, check if payload executes in browser without server round-trip. (2) Tools - DOM Invader (Burp Suite extension, identifies sources/sinks automatically), OWASP ZAP DOM XSS scanner, browser DevTools (inspect JavaScript execution paths from sources to sinks). (3) Common payloads - ,