TL;DR
- DOM-based XSS is a type of cross-site scripting attack where malicious code is handled on the client side via the browser’s Document Object Model (DOM).
- It matters because it bypasses traditional server-side defenses and exposes web applications to serious risks like data theft and session hijacking.
- Search-ready snippet: DOM-based XSS manipulates client-side JavaScript and DOM objects to inject malicious scripts directly in the browser.
Introduction
This guide is for developers, application security teams, and product managers working on securing modern web applications.
Cross-site scripting (XSS) remains one of the most common and dangerous vulnerabilities in web security. DOM-based XSS is a client-side variant that is harder to detect and block using server-side controls.
In this article, we’ll explain:
- What DOM-based XSS is and how it differs from other XSS types
- Real-world examples of DOM-based XSS
- How attackers exploit the DOM
- How to prevent it using best practices
What is DOM-Based XSS?
DOM-based XSS (Document Object Model-based Cross-Site Scripting) occurs when a web application’s client-side JavaScript writes untrusted data to the page without proper sanitization or validation. Unlike reflected or stored XSS, this attack doesn’t involve a server response that directly includes malicious scripts — everything happens in the browser.
How it works:
When user input (e.g., a URL parameter) is read by JavaScript and injected into the DOM (e.g., document.write, element.innerHTML, etc.), attackers can craft payloads that execute arbitrary code in the user’s browser.
Example attack vector:
let search = location.hash.substring(1);
document.getElementById(“output”).innerHTML = search;
If a user visits https://example.com#<img src=x onerror=alert(1)>, the browser will parse and execute the injected code.
Real-World Examples of DOM-Based XSS
- Search boxes: Apps that display search queries using innerHTML or document.write without encoding can be exploited.
- Client-side routing: Single Page Applications (SPAs) often read from location.hash or location.search, making them frequent targets.
- PostMessage abuse: Insecure handling of window.postMessage data may allow XSS injection.
High-profile sites such as Google, eBay, and others have previously reported DOM-based XSS bugs via their bug bounty programs.
Key JavaScript Sinks Vulnerable to XSS
DOM XSS arises when untrusted input flows into JavaScript “sinks” — DOM-manipulating methods that render data on the page.
Common dangerous sinks include:
- innerHTML
- outerHTML
- document.write()
- element.setAttribute()
- eval(), setTimeout(), setInterval()
Safe alternatives involve using:
- textContent instead of innerHTML
- DOM APIs like createElement() and appendChild()
- Strict Content Security Policy (CSP) enforcement
How to Prevent DOM-Based XSS
Here are proven techniques to protect against DOM-based XSS:
- Avoid unsafe DOM APIs — Prefer safe methods like textContent.
- Use input validation and output encoding — Escape untrusted input before rendering.
- Adopt a strict Content Security Policy (CSP) — Block inline scripts and unauthorized domains.
- Leverage security libraries — Use libraries like DOMPurify to sanitize HTML safely.
- Run automated security testing — Tools like Feroot’s platform can detect client-side JavaScript security risks including DOM XSS.
FAQ
What’s the difference between DOM-based XSS and reflected XSS?
Reflected XSS sends the payload to the server and reflects it back in the response. DOM-based XSS executes the payload entirely in the browser without involving the server response.
How do attackers exploit DOM-based XSS?
They trick users into clicking links with malicious payloads in URL fragments or parameters that get executed by vulnerable JavaScript in the browser.
Can CSP fully prevent DOM-based XSS?
CSP can help block many payloads by restricting inline scripts and unsafe functions, but it’s not foolproof — proper code hygiene is essential.
What tools detect DOM XSS vulnerabilities?
Feroot can detect client-side script injection issues. Get a glimpse of the capabilities by scheduling a demo today:
Is DOMPurify enough to stop DOM-based XSS?
It significantly reduces risk but must be used properly — sanitize only where HTML output is truly needed and still validate input.
