DOM-Based Cross-Site Scripting

While reflected and stored XSS involve server-side reflection of malicious input, DOM-based XSS exists entirely within the browser. The vulnerability lies in client-side JavaScript that unsafely processes data, never involving the server in the exploitation chain.

Client-Side Vulnerability Mechanics

Modern web applications execute extensive JavaScript that manipulates page content dynamically. This JavaScript often reads data from various sources—the URL, cookies, local storage, or user input—and uses that data to modify the page. When this data reaches a dangerous "sink" without proper sanitization, XSS becomes possible.

Sources provide attacker-controllable data. The URL hash (location.hash) is a classic source because it's directly controllable in crafted links and often doesn't even reach the server. URL parameters (location.search), the document referrer, cookies, and Web Storage all serve as potential sources.

Sinks are JavaScript functions or DOM properties that can lead to code execution. innerHTML is perhaps the most common dangerous sink—assigning user-controlled strings to element.innerHTML causes HTML parsing and script execution. document.write, eval, setTimeout with string arguments, and jQuery's html() method all pose similar risks.

Tracing Data Flows

Finding DOM XSS requires tracing how data flows from sources to sinks through JavaScript code. This differs fundamentally from finding reflected XSS, where you simply check whether input appears in server responses.

Start by identifying sources in the JavaScript code. Search for references to location, document.cookie, localStorage, and similar APIs that provide external data. Then follow how that data moves through variables and function calls until it reaches its final destination.

When data reaches a dangerous sink, you've found a potential vulnerability. The exploitability depends on any transformations or validations applied along the way. Some applications encode data properly before using it in sinks; others trust it completely.

Browser developer tools greatly assist this analysis. Setting breakpoints, inspecting variable values, and stepping through code execution reveals exactly how data flows and transforms. Modern browsers also provide console APIs for monitoring DOM modifications.

Exploitation Considerations

DOM XSS exploitation often requires different payloads than server-side XSS. The exact payload depends on the source and sink involved. URL fragments might need URL encoding. JavaScript string contexts require appropriate escape sequences.

Some DOM XSS vulnerabilities only execute in specific browser conditions. JavaScript that runs on page load, triggered by specific user actions or timing conditions, may require crafted links that create exactly the right execution context.

Reporting DOM XSS effectively requires clear demonstration of the vulnerability. Create proof-of-concept URLs that trigger the payload, document the vulnerable code path, and explain the conditions necessary for exploitation.