Making Of: The Sanitizer API by Frederik Braun | Nullcon Berlin

```json { "summary": "Overview\n\nFrederik Braun, Staff Security Engineer at Mozilla, presents the Sanitizer API—a proposed W3C incubator group specification with prototype implementations in Chrome and Firefox designed to address DOM-based cross-site scripting vulnerabilities. Despite being a well-understood problem, XSS remains the most reported security vulnerability for over a decade, particularly in single-page applications and Electron-based software.\n\nKey Topics\n\n1. DOM-Based XSS Problem\nThe fundamental vulnerability is simple: `element.innerHTML = attacker_controlled_string`. Braun traces his experience fixing XSS issues in Firefox UI and generalizing solutions for web applications, observing three common fix approaches: using text content instead of HTML, attempted encoding/escaping (often unsuccessful), and dealing with intertwined template and user input. He argues most could be fixed with a proper sanitizer.\n\n2. Initial Design & Critical Pitfalls\nThe first API design used parse-sanitize-serialize steps returning a string. However, this created double parsing: the sanitizer would parse and serialize to a string, then `innerHTML` would parse again. This causes MXSS (mutation XSS) vulnerabilities where subtle parsing differences between contexts allow attacker bypass.\n\nTechnical Details\n\n1. Fragment Parser Context Problem\nA critical insight from the HTML specification: two parsing algorithms exist. The document parser handles full HTML documents (used when loading pages), while the fragment parser handles partial HTML snippets (used by `innerHTML`) and crucially requires a context element. Different HTML elements have different parsing rules—table elements parse radically differently depending on context. The initial implementation incorrectly assumed a body context, failing for tables, select elements, and other context-sensitive elements.\n\n2. Sanitizer Bypass via Parsing Mismatch\nSecurity researcher Michael Benkowski reported a bypass: SVG content with nested HTML elements serialized one way through the fragment parser but differently through the document parser (used for iframe src assignment), bypassing sanitization and enabling XSS.\n\n3. Current Solution: setHTML() API\nThe solution integrates parsing, sanitization, and DOM insertion into a single operation:\n```\nelement.setHTML(input, {sanitizer: config})\n```\nThis uses the fragment parser with the correct context element, sanitizes the resulting tree, and appends it to the DOM atomically—preventing double parsing entirely. Alternative methods include `sanitize()` returning a document fragment and discouraged `sanitizeToString()` for strings.\n\nSecurity Scope & Limitations\n\nServer-side XSS is out of scope; the API focuses on client-side DOM-based vulnerabilities. Three known attack classes require consideration:\n\n1. DOM Clobbering: Injected elements confuse JavaScript by shadowing real properties. Mitigatable by configuring the sanitizer to remove name and id attributes.\n\n2. Script Gadgets: Framework-specific XSS via template syntax or library behavior. Universal prevention is impossible, but frameworks can configure their own sanitizers.\n\n3. MXSS: Remains vulnerable if code re-parses output afterward. Single parsing in the Sanitizer API mitigates this but does not completely solve it if developers parse again.\n\nDesign Principles\n\n- Safe by default: No configuration enables XSS; the API guarantees safety\n- Responsibility shift: XSS via Sanitizer API becomes a browser bug, not developer responsibility\n- Reuses browser parser: Future-proof against HTML syntax changes; avoids mismatches that plague external sanitizer libraries\n- Configurable within safety bounds: Applications can restrict HTML further but not weaken security\n\nContribution Paths\n\nDevelopers and researchers can contribute by: (1) testing for bypasses using `document.body.setHTML(evil)` on empty pages (security bounty eligible); (2) filing bug reports; (3) contributing to the web platform test suite; (4) participating in open specification questions on GitHub; (5) improving the JavaScript polyfill.\n\nKey Takeaway\n\nBraun emphasizes: \"Use the right HTML parser before, after, and in the middle.\" By integrating sanitization into the browser's actual HTML parser with proper context, the Sanitizer API avoids double-parsing pitfalls that have plagued external sanitizer libraries. This represents a fundamental shift toward making the browser itself responsible for a core security property.", "teaser": "Frederik Braun presents the Sanitizer API, a browser-native XSS prevention tool that integrates sanitization directly into the HTML parser to eliminate parsing mismatches and MXSS vulnerabilities that have plagued existing JavaScript sanitizer libraries.", "speakers": [ "Frederik Braun" ], "topics": [ "DOM-based XSS", "Sanitizer API", "HTML parsing", "MXSS mutation XSS", "Fragment parser context", "DOM clobbering", "Script gadgets", "Browser security" ] } ```