AI Summary
→ 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 INSIGHTS - **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. → NOTABLE MOMENT Frederik Braun notes that cross-site scripting remains one of the top three most reported vulnerabilities in the US National Vulnerability Database — despite Content Security Policy existing for roughly fifteen years. The implication is that technically sound solutions fail without adoption simplicity, which is precisely the problem `setHTML` is designed to solve. 💼 SPONSORS [{"name": "Bluehost", "url": "https://bluehost.com/vps"}] 🏷️ Sanitizer API, Cross-Site Scripting, Web Security, Content Security Policy, DOMPurify, Browser APIs