-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
Do I have to set a CSP header myself?
No, but enforcement has to come from somewhere. A response header is the sturdiest option, a parse-time <meta> works, and INJECT_META: true lets DOMFortify place the <meta> for you. The header is just more robust because <meta> injection only works during the initial parse. Whatever you choose, status().enforcementActive tells you if it took.
Does it need DOMPurify?
DOMPurify is the default and the well-trodden path, but no. SANITIZER accepts any object with .sanitize(str, cfg) or any function(str, cfg) => string, so you can plug in the native Sanitizer API or your own.
Will it break my page? It can, on purpose, if enforcement is on and the sanitizer is missing or throws. It fails closed rather than leak raw markup. Bundle and pin the sanitizer so that does not happen. If enforcement is off, DOMFortify is inert and changes nothing.
Does it stop all XSS?
No. It covers Trusted Types HTML sinks, and refuses script sinks. Inline event handlers, style sinks, and javascript: URLs are not Trusted Types sinks and stay open; pair DOMFortify with a script-src that drops 'unsafe-inline'. It is defense in depth, not a substitute for fixing XSS at the source.
Do I really have to load it first?
Yes. The default Trusted Types policy is winner-takes-all, and whoever registers it first owns every sink. Run DOMFortify first, inline in <head>. If something else claimed default already, DOMFortify will not install and will tell you so.
How do I know it is actually working?
Read status(). protected is true only when enforcement is on, the policy is owned, and the sanitizer passed its smoke test. reason explains any failure. For ongoing visibility, wire ON_VIOLATION to your telemetry.
Can I run it on only some pages, or with different settings per page?
Yes. EXCLUDE turns DOMFortify off entirely for matching URLs (which leaves those pages unprotected, by design), and URL_CONFIG applies per-URL config overrides for matching URLs.
Does it work in a bundler / framework build?
Yes, with two caveats: there is no window.DOMPurify in a bundle, so pass SANITIZER explicitly, and your bundler will not guarantee load order, so make sure init() runs before any DOM writes. For a plain <script>, the self-installing IIFE build (dist/fortify.min.js) is simpler.
Is it safe against prototype pollution and DOM clobbering? It is built to resist being quietly disabled by hostile page content: native references are captured at load, config is read own-key only, and the violation reporter cannot affect control flow. That hardens DOMFortify itself; it does not fix prototype pollution elsewhere in your app. See Security Goals and Threat Model.
What does it cost in size and dependencies? It is small and has no runtime dependencies. The sanitizer (for example DOMPurify) is the dependency you bring; DOMFortify just orchestrates it.