Re: [w3ctag/design-reviews] Early design review: Sanitizer API (#619)

I'm happy to see work in this direction. This is so frequently needed, and requiring authors to seek and include a library to provide basic security for any app that handles HTML was not ideal.

I took a look at the proposed API and will outline my thoughts below.

I like the sensible defaults approach, and the fact that "simple things should be easy" is an explicit goal. It's good that there is an optional config to customize these defaults, to cater to more specialized use cases. However, I noticed that even though there's [a very long default config](https://wicg.github.io/sanitizer-api/#default-configuration), it does not describe or afford customization of all rules required to properly sanitize HTML. For example, neither `<a>` elements, nor `href` attributes are dropped, but `javascript:` links need to be removed from links, which I imagine is part of the default sanitization. However, there is no way to specify or remove this behavior in the config, or any behavior relating to values of attributes. It would be good if the config could expose and afford customization on all sanitization rules. This could also allow for a more granular way to avoid DOM clobbering than stripping all ids. Perhaps this is what you mean by additional configuration options for 2.0?

It is unclear how authors can remove an element from the list of allowed elements, without re-specifying the entire allowlist of the default configuration. My understanding is that if they specify it in a block list, the behavior of the sanitizer changes to "anything goes except the blocklist". Exposing the config on `Sanitizer` instances (possibly read-only) could provide an easy solution for this use case. Exposing the default config as a static property on `Sanitizer` might be helpful too.

While I understand the reasons behind making the main `sanitize()` method return a `DocumentFragment`, it does feel a little unexpected from a DX perspective. Also, given that `sanitizeToString()` is merely a helper for serializing document fragments, I wonder if it would be better for the Web Platform if a property/method was added to `DocumentFragment` for serialization, instead of defining ad hoc helpers on more specialized APIs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/619#issuecomment-809700791