704: Sanitizer API with Frederik Braun

What It Covers

Frederik Braun, manager of Firefox application security at Mozilla, explains the newly shipped Sanitizer API — a browser-native solution to cross-site scripting (XSS). The episode covers `setHTML` vs `innerHTML`, sanitizer configuration with allowlists, integration with Content Security Policy, DOMPurify's role, and how the API handles custom elements and data attributes.

Key Questions Answered

• •setHTML as innerHTML replacement: Replace `element.innerHTML` with `element.setHTML(input)` to get browser-guaranteed XSS-safe HTML insertion. The method uses the browser's own HTML parser, so sanitization stays current as HTML evolves. No configuration required for basic usage — the default safe list handles common elements automatically, making it a near-direct search-and-replace upgrade with zero security expertise needed.
• •setHTML vs setHTMLUnsafe: Two methods exist by design. `setHTML` cannot be configured to allow scripts under any circumstance — XSS safety is guaranteed. `setHTMLUnsafe` mirrors React's "dangerously set inner HTML" naming pattern, signaling developer intent. Frederik Braun recommends only using the unsafe variant if a security engineer is actively involved in reviewing the configuration and its implications.
• •Allowlist configuration over blocklist: Rather than removing unwanted elements, configure a `new Sanitizer()` with an explicit `elements` array listing only what your use case requires — paragraph, anchor, bold, italic, blockquote, lists. This approach stays evergreen: future HTML elements are automatically excluded. Custom web components with dash-separated names like `dave-card` can be explicitly added to the allowlist by name.
• •Defense-in-depth with server-side sanitization: Server-side sanitization and `setHTML` serve complementary roles. Backend libraries sanitize on intake, but browser-side sanitization handles mismatches between server assumptions and the specific browser rendering the page. Academic research confirms that sanitizers outside the browser frequently fail on edge cases — malformed HTML, browser-specific parsing quirks, and newly introduced elements that backend libraries haven't yet catalogued.
• •CSP + Trusted Types integration: Content Security Policy's Trusted Types feature can be set to reject all `innerHTML`, `document.write`, `outerHTML`, and `insertAdjacentHTML` calls at runtime via a single HTTP header configuration. Combined with `setHTML`, this creates a hard enforcement layer where unsafe DOM manipulation throws errors rather than silently executing. Despite CSP existing since roughly 2010, over 80% of pages using it still lack sufficient XSS protection.
• •DOMPurify as the current fallback: For browsers not yet supporting the Sanitizer API, DOMPurify remains the recommended library — its author Mario Heiderich co-authored the Sanitizer API specification. DOMPurify weighs approximately 8.3KB gzipped. The progressive enhancement pattern is: check `if (window.Sanitizer)`, use `setHTML` if available, otherwise fall back to DOMPurify plus `innerHTML`. Firefox shipped the API first; Chrome support was imminent at recording time.