Sanitizer API

[annevk]

Request for position on an emerging web specification

• WebKittens who can provide input: @cdumez @rniwa

Information about the spec

• Spec Title: Sanitizer API
• Spec URL: https://wicg.github.io/sanitizer-api/
• GitHub repository: https://github.com/WICG/sanitizer-api
• Explainer (if not README.md in the repository):

Design reviews and vendor positions

• TAG Design Review: Early design review: Sanitizer API w3ctag/design-reviews#619
• Mozilla standards-positions issue: Sanitizer specification mozilla/standards-positions#106

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Anything else we need to know

This was previously raised in https://lists.webkit.org/pipermail/webkit-dev/2021-March/031731.html.

The API offers an innerHTML replacement that is supposed to be safe-by-default.

[annevk]

I personally think this is a good idea overall and as it gives developers a straightforward tool to combat XSS. Feedback I've given to date focused on simplifying the overall setup and making it better suited as a DOM API (e.g., operating on local names and namespaces rather than qnames).

[rniwa]

Yeah, the idea of introducing sanitizer API in the browser doesn't seem like a bad idea. I'm not sure about the exact API shape.

[annevk]

The API shape has been under discussion and WICG/sanitizer-api#193 captures what has some tentative agreement based on the meeting notes at WICG/sanitizer-api#192.

It essentially comes down to new HTML parser APIs that also support XSS filtering (and declarative shadow roots by default, as new HTML parser APIs should):

• Element.prototype.setHTML(input, { filter }): provides partial innerHTML parity. It parses, filters, and inserts.
• Document.parseHTML(input, { filter }): provides partial DOMParser parity. It parses, filters, and returns a Document object. (Reportedly an entry point used a lot in existing libraries.)

And then both of these get unsafe variants to achieve almost-full parity. I say almost, because there's currently nothing planned for XML, which seems fine.

Providing replacements for insertAdjacentHTML() is still on the table as well, but probably separately from the Sanitizer API effort.

I'm inclined to endorse this with "position: support", but wanted to give a bit more time for the community to review these changes.

[johnwilander]

I like this functionality being available to developers.

[annevk]

Having discussed this more with colleagues and given the lack of opposing feedback in this issue I suggest we label this as "position: support" one week from now.