Introduction

DOM manipulation attacks exploit client-side JavaScript that reads untrusted data and feeds it to a DOM API that interprets markup or executes code. The vulnerability lives entirely in the browser — the server may never see the payload at all — which is why server-side input validation is structurally incapable of stopping these bugs. If the sink is reachable from a source, the page is exploitable.

Traditional cross-site scripting is usually described as reflected (server echoes a parameter) or stored (server persists and later renders a payload). DOM-based attacks are a separate class: the unsafe transformation happens in front-end code. The payload can arrive via location.hash, a postMessage event, window.name, or localStorage, and never touch a server log, a WAF, or a backend template engine.

Once JavaScript runs in the victim's origin, the attacker owns the session. They can read cookies, exfiltrate tokens from localStorage, fire privileged XHRs as the user, modify DOM to phish credentials, and chain into CSRF or token theft. The blast radius is identical to stored XSS — the attack vector is just harder to see because it hides inside the client bundle.

The DOM Attack Surface

Every DOM attack fits a source→sink shape. A source is any browser API that returns attacker-controllable data. A sink is any API that interprets that data as markup, URL, or code. Your code review job is to find unbroken paths from one to the other.

Sources are easy to enumerate — they are browser-provided globals and properties. Anything the attacker can influence without authentication is in scope: the URL (hash, search, pathname), referrer, window name, message events, storage APIs, cookies, and form inputs. Even seemingly safe sources like the page's own document.title are tainted if they were ever derived from another source.

The reviewer heuristic is simple: grep the codebase for every sink on this list, then for each hit, trace the value back through variable assignments, function calls, template literals, and property reads until you either reach a constant (safe) or a source (finding). Static analysis tools automate this trace, but understanding the method is what lets you review the paths the tools miss.

DOM Clobbering

DOM clobbering is an attack where an attacker who can inject even sanitized HTML (no <script>, no event handlers) uses element IDs and name attributes to overshadow JavaScript variables and object properties. Browsers expose every element with an id as a property of window and document, and <form> / <img> / <a> elements with a name are exposed by name too. Injected HTML can therefore hijack lookups that the application assumed were its own globals.

Consider a common pattern: front-end code checks whether a config object is present before applying defaults.

1// The author expects `config` to be set by a previous <script> tag.
2// If it's missing, fall back to a default.
3const config = window.config || { apiBase: '/api', trackingPixel: null };
4
5// Later the trackingPixel URL is written to the DOM:
6const img = document.createElement('img');
7img.src = config.trackingPixel || '/default.png';
8document.body.appendChild(img);

If any user-controlled HTML ends up in the page — even through a sanitizer that allows <a> tags — an attacker can set window.config to a DOM element by clobbering it:

1<!-- Allowed by most HTML sanitizers -->
2<a id="config"></a>
3<a id="config" name="trackingPixel" href="javascript:alert(document.cookie)"></a>

When the page reads window.config, it no longer gets undefined — it gets an HTMLCollection of the two anchors. Property access config.trackingPixel returns the second anchor by its name attribute, and assigning that element to img.src stringifies it via the href attribute — which is javascript:alert(...). The sanitizer never touched an event handler; the attack works entirely through identifier shadowing.

1// Attach config to an object that the attacker cannot clobber.
2// You can't create a DOM element whose id puts a property under another object.
3window.__APP__ = window.__APP__ || {};
4const config =
5  typeof window.__APP__.config === 'object' && window.__APP__.config !== null
6    ? window.__APP__.config
7    : { apiBase: '/api', trackingPixel: null };
8
9// Always validate types before use:
10const src = typeof config.trackingPixel === 'string' ? config.trackingPixel : '/default.png';
11// And always validate URL schemes (see Prevention section).

HTML Injection via DOM Sinks

The single most common DOM bug is untrusted data reaching an HTML-parsing sink. The canonical sink is innerHTML, but every API that parses markup is equally dangerous.

1// A "search results" heading that echoes the user's query.
2const query = new URLSearchParams(location.search).get('q') ?? '';
3document.getElementById('results-header').innerHTML =
4  'Results for: ' + query;
5
6// Attacker visits /search?q=<img src=x onerror=alert(1)>
7// Browser parses the string, creates an <img>, fires onerror, runs JS.

Anything that parses HTML belongs in the same category: outerHTML, insertAdjacentHTML, document.write, and every framework wrapper that delegates to them.

1// jQuery — the $(html) and .html() shortcuts call innerHTML.
2$('#header').html(user.displayName); // XSS if displayName is attacker-controlled
3
4// React — dangerouslySetInnerHTML is a literal name-warning.
5<div dangerouslySetInnerHTML={{ __html: comment.bodyHtml }} /> // Trust boundary
6
7// Vue — v-html is identical in effect.
8<div v-html="comment.bodyHtml"></div>
9
10// Angular — bypassSecurityTrustHtml disables the sanitizer.
11this.trustedHtml = this.sanitizer.bypassSecurityTrustHtml(raw);
12
13// Svelte — {@html raw} is Svelte's version of the same exit hatch.
14{@html user.bio}

These APIs exist because sometimes you really do need to render HTML (e.g., a markdown renderer output). That is fine — but only when the string has been sanitized by a library whose only job is to sanitize, and whose rules you have audited. Never sanitize with a regex; HTML cannot be parsed with regular expressions.

1// Case 1: You just want to show a string. Use textContent.
2const header = document.getElementById('results-header');
3header.textContent = 'Results for: ' + query; // cannot inject markup
4
5// Case 2: You need structure and attributes. Use the DOM builder API.
6const img = document.createElement('img');
7img.src = '/thumbs/' + encodeURIComponent(thumbId); // browser-escapes, not sanitized
8img.alt = userProvidedAlt; // setAttribute would also work
9document.body.appendChild(img);
10
11// Case 3: You must render HTML from untrusted markdown/rich text.
12import DOMPurify from 'dompurify';
13const clean = DOMPurify.sanitize(comment.bodyHtml, {
14  USE_PROFILES: { html: true },
15  FORBID_TAGS: ['style'],
16  FORBID_ATTR: ['style'],
17});
18el.innerHTML = clean; // clean was produced by a sanitizer, not by string concat

DOM-Based XSS: Source-to-Sink Tracing

The most reliable way to find DOM-based XSS in a review is the sink-first trace. You don't try to enumerate every possible attacker input — there are too many, and the framework may rename them. Instead, you locate every dangerous sink and walk upstream, asking for each read: "could this value contain attacker-controlled data?" You stop when you hit a literal constant (safe) or a source (finding).

Here is a realistic example that looks harmless at first glance.

1// Single-page app uses the URL fragment to select a tab.
2function renderTab() {
3  const tabId = decodeURIComponent(location.hash.slice(1)) || 'overview';
4  const template = tabTemplates[tabId] ?? tabTemplates.overview;
5  document.getElementById('tab-content').innerHTML = template(tabId);
6}
7window.addEventListener('hashchange', renderTab);
8renderTab();
9
10// ...elsewhere in the codebase:
11const tabTemplates = {
12  overview: (id) => '<h2>' + id + '</h2><p>Welcome.</p>',
13  details: (id) => '<h2>' + id + '</h2><p>Details view.</p>',
14};

Work the trace backwards from the sink. Write it out like a proof — every step is either "safe because..." or "tainted because..."

1. Sink: document.getElementById(...).innerHTML = template(tabId). Parses HTML. Need to prove the RHS is trusted.
2. RHS: template(tabId). The template concatenates strings into <h2>...</h2>. Any reachable id value is spliced into HTML context unescaped.
3. template argument: tabId. Where does it come from? One line above.
4. tabId definition: decodeURIComponent(location.hash.slice(1)) || 'overview'. Right side of the || is a literal. Left side starts with location.hash — a source.
5. Finding: attacker-controlled location.hash flows through decodeURIComponent (which is not a sanitizer — it decodes) into an HTML-context string concat, which reaches innerHTML.
6. Proof-of-concept: https://app.example.com/#<img src=x onerror=alert(1)>. Remediation: use textContent for the heading, or DOMPurify if HTML is required. Validate tabId against the known keys before any interpolation.

The subtle lesson: decodeURIComponent looks like it does something security-relevant because it has a complicated name — but it is a decoder, not a sanitizer. Many reviewers mentally discount a value once they see "some transformation" applied, even when the transformation doesn't remove the dangerous characters.

Prevention Techniques

Prevention is layered. The outer layer is API choice: prefer DOM APIs that do not parse HTML. The middle layer is sanitization for the rare cases where you truly must render HTML. The inner, browser-enforced layer is Trusted Types plus CSP, which turns a forgotten innerHTML = somewhere in a 500-file app from a shipped vulnerability into a runtime exception.

1// Text content? Always textContent.
2el.textContent = userProvidedString;
3
4// Building structured DOM? Use createElement + setAttribute.
5const a = document.createElement('a');
6a.textContent = linkLabel; // safe
7// For URL attributes, validate scheme:
8const url = new URL(userHref, location.origin);
9if (url.protocol === 'http:' || url.protocol === 'https:') {
10  a.href = url.href;
11}
12
13// Setting classes or data? Dedicated APIs exist.
14el.classList.add('active');
15el.dataset.userId = String(userId);

1import DOMPurify from 'dompurify';
2
3// Start with a narrow allowlist. Widen only with justification.
4const clean = DOMPurify.sanitize(dirty, {
5  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br', 'ul', 'ol', 'li', 'code', 'pre'],
6  ALLOWED_ATTR: ['href', 'title'],
7  ALLOW_DATA_ATTR: false,
8  FORBID_TAGS: ['style', 'form', 'svg', 'math'],  // mXSS vectors
9  FORBID_ATTR: ['style', 'onerror', 'onload'],
10  ALLOWED_URI_REGEXP: /^(?:(?:https?|mailto):|\/)/i,
11});
12el.innerHTML = clean;
13
14// Keep DOMPurify up to date. Its version history is a history of mXSS bypasses.

1// Define a single sanitizer policy. All innerHTML assignments must
2// receive a TrustedHTML object produced by this policy, or the
3// browser throws a TypeError at the sink.
4if (window.trustedTypes && trustedTypes.createPolicy) {
5  const policy = trustedTypes.createPolicy('app-html', {
6    createHTML: (dirty) => DOMPurify.sanitize(dirty, { RETURN_TRUSTED_TYPE: true }),
7  });
8
9  el.innerHTML = policy.createHTML(userMarkdown);
10}

1Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-html default;
2
3# Effect:
4#  - innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, etc.
5#    all throw TypeError when given a raw string.
6#  - Only TrustedHTML / TrustedScript / TrustedScriptURL values are accepted.
7#  - This catches every third-party widget, legacy code path, and
8#    forgotten template helper that was still calling innerHTML with user data.

Frameworks each have a preferred-safe and a dangerous path. Know both for every framework in the repo.

• React: JSX auto-escapes text children and attribute values. Never use dangerouslySetInnerHTML without sanitization; never build href with string concat — compute the URL with new URL() and validate the protocol.
• Vue: {{ mustache }} and v-bind escape by default. v-html is the exit hatch; treat it like dangerouslySetInnerHTML.
• Angular: the DomSanitizer escapes by default when binding to [innerHTML]. bypassSecurityTrustHtml and friends disable the sanitizer — audit every call.
• Svelte: {value} escapes. {@html value} is the exit hatch.
• Solid / Lit / Preact: same pattern — default-safe template syntax, one named dangerous API. Grep for the dangerous API across the whole repo on every security review.

Security Tools & Linters

DOM sink review is something static tools do well. You should layer a static check that fails the build with a runtime check that fails the request.

Here is a drop-in Semgrep rule for catching the most common sink:

1rules:
2  - id: no-user-input-to-innerhtml
3    message: >-
4      Assignment to .innerHTML from a non-literal value. Use textContent for
5      plain strings, or DOMPurify.sanitize() for rich HTML.
6    severity: ERROR
7    languages: [javascript, typescript]
8    patterns:
9      - pattern-either:
10          - pattern: $EL.innerHTML = $VAL
11          - pattern: $EL.outerHTML = $VAL
12          - pattern: $EL.insertAdjacentHTML($POS, $VAL)
13      - pattern-not: $EL.innerHTML = "..."
14      - pattern-not: $EL.innerHTML = `...`
15      - pattern-not: $EL.innerHTML = DOMPurify.sanitize(...)
16      - pattern-not: $EL.innerHTML = $POLICY.createHTML(...)

ESLint config for a React app — the lines that matter are the few sink-related rules. Add them to every frontend repo, not just the ones you think are security-sensitive.

1{
2  "plugins": ["no-unsanitized", "@microsoft/sdl"],
3  "rules": {
4    "no-unsanitized/method": "error",
5    "no-unsanitized/property": "error",
6    "@microsoft/sdl/no-inner-html": "error",
7    "@microsoft/sdl/no-document-write": "error",
8    "@microsoft/sdl/no-insecure-url": "error",
9    "react/no-danger": "warn"
10  }
11}