Skip to content
Cure53 edited this page Sep 9, 2026 · 2 revisions

DOMFortify Wiki

DOMFortify bolts Trusted Types onto a page so that old, vulnerable HTML sinks get sanitized before bad markup ever reaches the DOM, without touching the application code. It claims the realm's default Trusted Types policy and routes every dangerous sink through a sanitizer (DOMPurify by default). Script sinks like eval and script.src are refused, because there is no safe way to sanitize executable code.

It is small, has no runtime dependencies, and tells you honestly whether you are actually protected via status().

The 60-second version

  • You have legacy code doing el.innerHTML = userInput in a hundred places and you cannot refactor it all.
  • DOMFortify becomes the one policy the browser consults for every such sink, and sanitizes the input there.
  • It does not turn enforcement on by itself by default, but it can: a response header is best, a parse-time <meta> works, and INJECT_META lets DOMFortify place that <meta> for you. Whichever you pick, status().enforcementActive tells you if it took.
  • When enforcement is off, DOMFortify still claims the default policy (so nothing else can) but routes nothing and reports enforcement-inactive. If some other code grabbed default first, it does not install and does not vouch for that policy. Either way it says so through status(); it never silently pretends to protect you.

Pages

What it is not

DOMFortify is not a replacement for fixing XSS at the source, and it is not a sanitizer itself, it orchestrates one. It covers exactly the Trusted Types sinks: every HTML sink is sanitized and every script sink is refused, including setAttribute('onclick', ...). What stays open is the residue no policy is consulted for: function assignment to a handler property, a javascript: URL assigned as a property, and style/CSS injection. See Risks and Footguns for the precise boundary.

Clone this wiki locally