scan.now
Premium Scan a site

Scan JavaScript for DOM-Based XSS Risks

Enter a page that loads the client application. Scan.now reviews inline and same-origin scripts for browser-controlled inputs paired with dangerous HTML or code-execution sinks.

Enter the exact public page to inspect. No form is submitted and no data is modified.

A registered account is required to run this test. Finding status, evidence, affected locations and remediation are Premium-only. How active scanning works · Acceptable use

Finding the two halves of a DOM XSS data flow

DOM-based XSS happens entirely in client-side code. JavaScript reads attacker-influenced data from a source such as location.search, location.hash, document.referrer, storage or postMessage, then passes it to a sink that interprets text as HTML or code.

Scan.now reviews inline scripts and a bounded set of same-origin JavaScript files for recognised sources and dangerous sinks. When both appear, it reports a candidate for developer review. Static proximity is not proof that data flows between them, so this check deliberately reports information rather than claiming confirmed exploitation.

Put this result in context

This scanner answers one part of the review. Continue with XSS Scanner for confirm reflected script injection in a url parameter, then JavaScript Libraries for outdated libraries with known cves. These are separate checks because a strong result here does not prove that the adjacent surface is healthy.

For the background behind these signals, read Cross-Site Scripting (XSS) Explained: Reflected, Stored, DOM-Based and How to Prevent It and Outdated JavaScript Libraries: Why Old jQuery and Angular Are a Real Risk and How to Find Them. The DOM XSS source and sink review check reference explains the exact test, evidence and remediation used in the report. The Scan.now methodology explains request limits, scan boundaries and what the scanner deliberately does not attempt.

Browser-controlled sources and dangerous sinks

The check is deliberately bounded to the signals below.

Coverage areaWhat the scanner examines
Browser-controlled sourcesURL components, referrer, web messaging and browser storage APIs are recognised as places untrusted data can enter.
HTML and code sinksinnerHTML, outerHTML, insertAdjacentHTML, document.write, eval, Function and string-based timers are highlighted.
Same-origin script sampleInline code and up to eight referenced same-origin scripts are inspected; raw source is not retained in the report.

Candidate data flows and clean static reviews

A scan result is evidence with a boundary, not a guarantee about every route.

Candidate found

At least one source and one sink exist in the inspected code. Trace the specific value through assignments, transformations and framework helpers.

No pair found

The sampled scripts did not contain a recognised source-and-sink combination. Bundling, dynamic imports and framework abstractions can hide flows.

Not a confirmation

A candidate may be safe because the values never meet or are sanitised. Browser-led data-flow testing is needed before calling it exploitable.

Safe DOM construction and trusted data boundaries

Use the recommendations below to address confirmed findings and strengthen the surrounding control.

  1. Use text-only DOM APIs

    Assign untrusted text with textContent and create elements and attributes through DOM methods rather than HTML strings.

  2. Sanitise unavoidable HTML

    Use a maintained allow-list sanitizer at the final insertion point and keep its configuration narrow.

  3. Validate postMessage origins

    Check event.origin against exact trusted origins and validate the message schema before using any field.

  4. Adopt Trusted Types

    In supported browsers, require trusted types for script sinks and centralise the few audited policies that may create HTML.

  5. Use CSP as containment

    A strict nonce-based policy reduces exploitability and produces violation reports, but does not repair the unsafe data flow.

How it works

  1. Enter a client-application page

    Use a page that loads the JavaScript bundle or feature you want reviewed.

  2. Sources and sinks are inventoried

    Inline code and bounded same-origin scripts are searched without executing them.

  3. Developers trace candidates

    The report names the APIs found and clearly separates a review candidate from confirmed reflected XSS.

What this tool checks

1 checks across 1 areas. Each links to its reference page with the test, the risk and the fix.

Full reference

Page content and JavaScript

1 check

The ones that most often decide the grade:

Medium DOM XSS source and sink reviewInline client code contains both attacker-controlled DOM sources and dangerous rendering or execution sinks.

Related tools

Continue the review with four checks that cover adjacent parts of the same attack surface.

All tools
Active Security XSS Vulnerability Scanner

Confirm reflected script injection in a URL parameter
Websites JavaScript Library Vulnerability Scanner

Outdated libraries with known CVEs
Websites Security Headers Checker

CSP, HSTS, frame and MIME policies
Active Security API Surface Scanner

Inventory API hints, OpenAPI documents and route counts

Guides for this tool

Background reading written to go with these results.

8 min read · Updated Sep 19, 2026 Cross-Site Scripting (XSS) Explained: Reflected, Stored, DOM-Based and How to Prevent It

XSS lets an attacker run their own script in your users' browsers. The three types, what an attacker does with it and the layered...

Read the guide
8 min read · Updated Sep 20, 2026 Outdated JavaScript Libraries: Why Old jQuery and Angular Are a Real Risk and How to Find Them

A page that ships an old library ships its known vulnerabilities. How Retire.js-style detection works, the most common vulnerable...

Read the guide
13 min read · Updated Sep 13, 2026 Website Security: What a Vulnerability Scan Looks For and How to Fix It

A website vulnerability scan checks the parts of a site an attacker can reach without logging in: Transport security, HTTP headers,...

Read the guide
8 min read · Updated Sep 12, 2026 What Is a Vulnerability Scan? Types, Limits and What the Results Mean

A vulnerability scan checks a system against a list of known weaknesses and reports what matches. The types of scan, the difference...

Read the guide
8 min read · Updated Sep 14, 2026 Passive vs Active Scanning: What Each Can Find and When Each Is Appropriate

Passive scanning observes normal responses; active scanning sends crafted requests to trigger flaws. The boundary, why it matters...

Read the guide
9 min read · Updated Sep 18, 2026 How to Read a Security Scan Report: Severity, False Positives and What to Fix First

A scan report is a list of findings with severities, and the hard part is deciding what matters. How severities are assigned, how to...

Read the guide

Frequently asked questions

What is the difference between reflected and DOM XSS?

Reflected XSS arrives in the server's HTML response. DOM XSS is created by browser-side JavaScript after the response, sometimes using only a URL fragment the server never receives.

Why is a source and sink pair not proof?

They may be in unrelated functions, behind unreachable branches or connected only after correct sanitisation. Static pattern matching identifies where human review is valuable.

Is innerHTML always vulnerable?

No. Constant trusted markup can be safe, and rigorously sanitised content can be acceptable. It is dangerous when attacker-controlled data can reach it without the right policy.

Does the scanner execute my JavaScript?

No. It reads a bounded amount of inline and same-origin source. Runtime-only bundles and behaviour after interaction require browser testing.