DOM XSS source and sink review: What It Means and How to Fix It

Inline client code contains both attacker-controlled DOM sources and dangerous rendering or execution sinks.

Do this: Trace browser-controlled sources and replace unsafe HTML/code sinks. Client-side code can execute attacker input without that input ever appearing in server HTML.
PassNo inline source/sink pair was identified.
MediumA source/sink pair needs browser confirmation.

The fix, in one snippet

Example to adapt Use text, not markup
element.textContent = value;  // not innerHTML

Illustrative values. Change the paths, hostnames and options to match your own site before using it.

The sections below explain what is tested, why it matters and the alternatives.

What we test

This static review matches browser-controlled sources such as location and postMessage with sinks such as innerHTML, document.write and eval. It does not execute JavaScript, so a match requires browser confirmation.

Why it matters

DOM XSS can execute entirely in the browser and therefore be invisible in the server's HTML response.

How to fix it

Use textContent and safe DOM construction, validate message origins, avoid string-to-code APIs and apply Trusted Types where supported.

Where this fits

DOM XSS source and sink review is check 7 of 19 that the dom xss scanner runs under page content and javascript, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.

Fix this one first

Above it in the same category sits Reflected cross-site scripting (high), where a GET parameter was returned as executable script markup in the response. An attacker who has that does not need this, so it is the better use of the same hour.

What fixing this still leaves open

DOM XSS source and sink review closes one route in. Immediately below it: Open redirect, where a redirect-like GET parameter accepted an external Scan.now URL; POST form without recognisable CSRF protection, where a POST form has no recognisable anti-CSRF field; Structural accessibility basics, where structural HTML checks found missing accessible names, image alternatives, document language or skipped heading levels.

Found in the same scan

The dom xss scanner reports this alongside checks from other categories that are at least as serious, including Path traversal / local file inclusion, where a path-like parameter returned a known local operating-system file signature, and Session token exposed in URL, where a session-like token name appears in a discovered URL. A single run of dom xss scanner answers all of them at once.

Prompt for an AI Hand this check to an assistant Sign in to copy it
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.

Finding: DOM XSS source and sink review (medium severity)
Scanner check id: dom-xss-static
17 more lines, including the evidence and the exact fix

The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.

Sign in with Google

Signing in is free and takes one click. We store your email address and nothing else.

References

  1. OWASP DOM XSS Prevention Cheat Sheet