DOM-based Cross-Site Scripting (XSS)

Description

DOM-based Cross-Site Scripting (XSS) is a variant of XSS where the entire exploit occurs in the Document Object Model (DOM) within the victim's browser, without sending malicious data to the server. In DOM-based XSS, the vulnerability arises when client-side scripts (e.g., JavaScript) read or write to the DOM using insecure methods (such as document.location, document.write, or innerHTML) with untrusted data. As a result, attackers can manipulate the browser environment to inject and execute malicious code directly.

Because the payload never reaches the server (or is not processed by the server in a vulnerable way), traditional server-side filters and firewalls may fail to detect or block it. DOM-based XSS can be harder to trace and mitigate if developers do not inspect client-side logic carefully.

Examples

Insecure DOM Manipulation

Consider a script that reads a parameter from the URL and sets it as HTML content:

// Example of an insecure snippet
let userParam = new URLSearchParams(window.location.search).get('text');
document.getElementById('output').innerHTML = userParam;

If an attacker crafts a URL like:

https://example.com/page?text=<script>alert('DOM XSS');</script>

the script will inject the untrusted HTML directly into the page's DOM, executing the attacker's payload.

Using location.hash

In single-page applications, developers often store state or data in the URL hash. If a script directly injects the hash value into the DOM, an attacker can pass malicious code in the hash fragment:

// Reading window.location.hash and directly rendering it
let hashContent = window.location.hash.substring(1); // e.g. '#<script>...</script>'
document.getElementById('hashOutput').innerHTML = decodeURIComponent(hashContent);

Anyone visiting a link with a crafted hash (e.g., https://example.com/#%3Cscript%3Ealert('XSS')%3C/script%3E) would execute the attacker's injected script.

Remediation

1. Safe DOM Manipulation Methods
   • Use APIs that automatically treat user data as text rather than HTML. For instance, use textContent instead of innerHTML.
   • Avoid dynamic insertion of HTML where possible. If absolutely necessary, use robust sanitization libraries (e.g., DOMPurify) to remove dangerous elements.
2. Proper Encoding and Escaping
   • When setting content in the DOM, ensure it is properly escaped for the appropriate context.
   • For example, if injecting into an HTML context, HTML-encode special characters to prevent script execution.
3. Validate and Sanitize Input
   • Although DOM-based XSS bypasses the server, validating and restricting the format of query parameters or hash fragments on the client side can reduce malicious opportunities.
   • Use regular expressions, built-in parsers, or sanitization routines to filter out disallowed characters or code.
4. Content Security Policy (CSP)
   • A well-configured Content Security Policy can reduce the risk of script injection even if some DOM-based vulnerabilities exist.
   • For instance, disallow inline scripts and only allow scripts from trusted sources to limit the effect of malicious injections.