Home

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, or if some other code grabbed the default policy first, DOMFortify stays inert and says so. It never silently pretends to protect you.

Pages

• Installation and Usage - install, turn enforcement on, configure, read status.
• How It Works - the mental model, with data-flow diagrams.
• Security Goals and Threat Model - what it defends, what it assumes, what is out of scope.
• Risks and Footguns - the sharp edges, in plain terms.
• FAQ - quick answers.

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 only covers Trusted Types sinks; inline event handlers, style sinks, and plain URL navigation are not Trusted Types sinks and stay open. See Risks and Footguns for the full list.