---
{
  "title": "DOM-based cross-site scripting",
  "summary": "DOM-based XSS arises when browser-side code moves untrusted data into a dangerous execution or markup sink.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: DOM based XSS Prevention",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

DOM-based XSS arises when browser-side code moves untrusted data into a dangerous execution or markup sink. The input may come from URLs, messages, or stored browser data without passing through a server response. Safe text insertion and context-specific handling matter at the client-side boundary.

## A practical example

A search page reads a term from its URL and displays it with a text API rather than setting HTML. The review follows the term through each browser-side transformation to ensure it never becomes script or executable markup.

## What to check

Trace sources to sinks in client code, prefer safe DOM APIs, and validate message origins. Review third-party components that perform their own rendering and test the actual browser behavior.

## A common pitfall

Server-side filtering cannot protect values that originate and are transformed entirely in the browser. A framework can also become unsafe when code bypasses its normal rendering protections.

## Think it through

Why inspect location and message inputs during frontend review?

**Answer:** They can supply untrusted data directly to browser code, which may turn that data into executable output.

## The dangerous transformation may happen after loading

A fictional dashboard reads a tab name from the page URL and uses it to build a heading. The initial HTML response may contain no untrusted markup at all. The risk appears later, when client-side code reads the value and places it into a browser operation that interprets HTML. Looking only at the server template would miss the relevant path.

Describe the path with three questions: where does the value originate, what transformations occur, and which final operation consumes it? URL components, browser storage, messages from other windows, and API responses can all be sources. The final sink determines whether the value becomes visible text, a URL, markup, or executable behavior.

Frameworks often provide safe text rendering by default, but escape hatches and third-party widgets can bypass it. A developer may insert raw HTML for convenience or pass a value into a library with its own interpretation rules. Review those boundaries explicitly instead of assuming that every component inherits the main framework's protections.

## Practice tracing a client-side value

Build a small local page that reads a harmless label from a query parameter. First render it using a text-only API, then inspect the code path of an intentionally unsafe training variant. Explain the difference without constructing a harmful payload. Include an empty label and a label containing ordinary punctuation to check usability.

A repair should cover the actual unsafe sink and any related rendering paths, including previews and error messages. If rich markup is a real requirement, define a sanitizer policy and ensure later transformations do not invalidate it. Browser-side testing complements source review because the DOM created after script execution may differ substantially from the original response.

## Related concepts

- [[xss]]
- [[output-encoding]]
- [[html-sanitization]]