DOM XSS Lab: Run Script Straight From the URL Bar

This article explains DOM-based XSS through a practical lab exercise where attackers inject malicious code via the URL fragment to trigger JavaScript execution in the browser. The vulnerability exists entirely on the client side—the server never sees the dangerous input because URL fragments (the part after #) are not sent to servers—making it invisible to server-side firewalls and filters. Understanding DOM XSS is critical because modern web applications perform significant logic in the browser, creating widespread exposure to this attack vector.

• How the QuickDocs vulnerability worksThe application reads the URL fragment using location.hash and inserts it directly into the page using innerHTML without escaping or sanitizing the content. Because innerHTML parses any markup you provide as actual HTML and DOM, an attacker can inject elements like img tags with error handlers that execute JavaScript when the page loads.
• Why server-side defenses completely miss itURL fragments after the # symbol never reach the server—browsers handle them entirely client-side. This means server-side filters, WAFs, and security tools have no visibility into the payload and cannot block it. The vulnerability lives purely in the JavaScript code, so the fix must be implemented in the browser code, not on the backend.
• Attack execution using image error handlersThe classic payload uses an img element with a broken source and an onerror event handler that automatically triggers when the browser fails to load the image. The handler can call the page's solve function or perform any other malicious action, demonstrating that injected elements and their event handlers fire immediately upon insertion into the DOM.
• Real-world prevalence and scopeDOM XSS is widespread in modern applications because so much code runs in the browser rather than on servers. Fragment-based, location-based, and postMessage-based vulnerable sinks are common findings in bug-bounty programs, and the attack can steal session tokens, perform unauthorized actions, or rewrite page content just like reflected or stored XSS.
• Proper fix: textContent instead of innerHTMLThe primary defense is to use textContent when displaying user-controlled text instead of innerHTML, since textContent writes plain text that cannot be parsed as HTML or execute code. If HTML construction is necessary, input must be sanitized using a trusted library like DOMPurify before insertion.
• Multi-layered defense strategyBeyond textContent and sanitization, developers should implement Content-Security-Policy headers as a backstop to prevent injected inline scripts from running. Additionally, developers should grep their front-end code for dangerous sinks like innerHTML, document.write, and insertAdjacentHTML, then trace whether these functions receive data from the URL, fragment, or postMessage.
• Threat modeling: treat client-side sources as untrustedThe URL, URL fragment, postMessage data, and browser storage can all be attacker-controlled and should never be trusted. Even though these sources appear local and under user control, any data flowing from them into a dangerous sink creates an exploitable DOM XSS vulnerability.

Bottom line: DOM-based XSS occurs when JavaScript unsafely writes untrusted client-side input (typically from the URL fragment) into the page using innerHTML, and this attack bypasses all server-side defenses because the vulnerable data never reaches the server. The fix is to use textContent for user text, sanitize HTML with libraries like DOMPurify if HTML must be constructed, and implement Content-Security-Policy as an additional layer of protection.