DOM-based XSS Deep Dive

#DOM-based XSS: The Invisible Vulnerability#link

Now that you have mastered Reflected and Stored XSS, we tackle the most elusive variant: DOM-based XSS. Unlike the previous types, DOM-based XSS vulnerabilities exist entirely in client-side JavaScript code. The server may never see or process the malicious payload — the attack happens entirely within the browser's Document Object Model (DOM).

This makes DOM-based XSS invisible to traditional server-side security tools, WAFs (Web Application Firewalls), and network-level scanners. It requires understanding how JavaScript manipulates the DOM and how user-controlled data flows from sources to sinks.

Sources and Sinks: The Core Concept

DOM-based XSS is best understood through the concept of sources and sinks. A source is any JavaScript property that can be controlled by an attacker. A sink is a JavaScript function or property that can cause JavaScript execution if it receives malicious data.

A DOM-based XSS vulnerability exists when data flows from a source to a sink without proper sanitization. The key insight is that the server is often completely uninvolved — the payload may be in the URL fragment (after the #), which is never sent to the server.

// Classic DOM-based XSS example
// URL: https://example.com/page#<img src=x onerror=alert(1)>

// Client-side JavaScript:
var hash = location.hash.substring(1);  // SOURCE: gets the fragment
document.getElementById('content').innerHTML = hash;  // SINK: writes to DOM

// The fragment (#...) is NEVER sent to the server
// Server-side WAFs and logging never see the payload
// The attack happens entirely in the browser

Common DOM-based XSS Patterns

Let's examine the most common patterns where DOM-based XSS occurs in real-world applications.

// Pattern 1: innerHTML assignment from URL parameter
var params = new URLSearchParams(location.search);
var name = params.get('name');
document.getElementById('greeting').innerHTML = 'Hello, ' + name;
// Attack: ?name=<img src=x onerror=alert(1)>

// Pattern 2: document.write from location hash
var content = location.hash.slice(1);
document.write('<div>' + content + '</div>');
// Attack: #<script>alert(1)</script>

// Pattern 3: eval() with user input
var config = location.hash.slice(1);
var settings = eval('(' + config + ')');
// Attack: #'},alert(1),({//

// Pattern 4: jQuery $() selector from URL (older jQuery)
var target = location.hash;
$(target).show();
// Attack: #<img/src=x onerror=alert(1)>
// jQuery interprets strings starting with < as HTML

// Pattern 5: postMessage handler without origin validation
window.addEventListener('message', function(e) {
  document.getElementById('result').innerHTML = e.data;
});
// Any origin can send a malicious postMessage

Tracing Data Flow: A Systematic Approach

Finding DOM-based XSS requires tracing data flow from sources to sinks through the JavaScript code. Here is a systematic methodology:

• ▪Identify all sources: Search the JavaScript for location, document.URL, document.referrer, window.name, postMessage, and storage APIs
• ▪Identify all sinks: Search for innerHTML, document.write, eval, setTimeout with strings, jQuery $(), and similar dangerous functions
• ▪Trace the data flow: Follow how data moves from each source through variables, functions, and assignments to reach sinks
• ▪Check for sanitization: Determine if any sanitization or encoding occurs along the data flow path
• ▪Craft payloads: Based on the context at the sink, craft appropriate payloads

// Complex data flow example
// URL: https://app.com/dashboard#section=profile

// Source: location.hash
var hash = location.hash;

// Data flows through a parser function
function parseHash(h) {
  var parts = h.split('=');
  return {
    key: parts[0].replace('#', ''),
    value: parts[1]
  };
}

var parsed = parseHash(hash);

// Data flows to a router function
function routeToSection(section) {
  if (section === 'profile') {
    loadProfile();
  } else {
    // SINK: innerHTML with attacker-controlled data
    document.getElementById('content').innerHTML =
      '<h1>Section: ' + decodeURIComponent(parsed.value) + '</h1>';
  }
}

routeToSection(parsed.key);

// Attack: #section=<img src=x onerror=alert(1)>
// The 'key' is 'section' (truthy check passes)
// The 'value' flows unsanitized into innerHTML

Hands-On: Exploiting DOM-based XSS

Let's exploit a real-world-style DOM-based XSS vulnerability in a single-page application that uses the URL hash to determine which content to display.

// Vulnerable SPA code (simplified)
// File: app.js

window.addEventListener('hashchange', renderPage);
window.addEventListener('load', renderPage);

function renderPage() {
  var page = location.hash.slice(1) || 'home';
  var template = document.getElementById('tpl-' + page);

  if (template) {
    document.getElementById('main').innerHTML = template.innerHTML;
  } else {
    // Fallback: display the page name directly
    document.getElementById('main').innerHTML =
      '<h2>Page not found: ' + page + '</h2>';
  }
}

// Attack URL: https://app.com/#<img src=x onerror=alert(document.cookie)>
// Since no template with ID 'tpl-<img...>' exists,
// the fallback branch executes, injecting our payload into innerHTML

Why DOM-based XSS Evades Traditional Defenses

DOM-based XSS is particularly dangerous because it bypasses most traditional security controls:

• ▪WAFs (Web Application Firewalls): The payload may be in the URL fragment, which is never sent to the server or WAF
• ▪Server-side input validation: The server never processes the malicious input
• ▪Static analysis tools: Client-side JavaScript is harder to analyze than server-side code
• ▪Automated scanners: Many scanners don't execute JavaScript or analyze client-side data flows
• ▪Log analysis: The payload doesn't appear in server access logs

#What's Next#link

You now have a solid understanding of all three XSS types. In the next lesson, we will level up your skills with advanced payload crafting techniques — learning to create payloads that work across different contexts and achieve specific exploitation objectives.