search

WICG / sanitizer-api

https://wicg.github.io/sanitizer-api/
Other
231 stars 31 forks source link

Solving safe/unsafe defaults #233

Open annevk opened 5 months ago

annevk commented 5 months ago

We have a problem currently that new Sanitizer() ends up being the same configuration for safe and unsafe, with completely different effects. This makes it really hard to design an API to manipulate the policy as the implications for safe and unsafe are different.

To solve this I think we could do the following:

  1. Introduce Sanitizer.default() that returns the configuration we want setHTML() to use when no configuration is provided.
  2. Make setHTML()'s SetHTMLOptions's sanitizer default to "default" rather than {}. setHTMLUnsafe() will continue to default to {}. "default" here is an enum value that means Sanitizer.default() and is needed to make things work IDL-wise. It will also provide us with a way forward for other named policies we might want to add in the future.
  3. new Sanitizer() now represents an empty policy. So if you pass that to setHTML() you only get the XSS-blocklist impacting you.
  4. We can continue to keep get() and getUnsafe(). get() is useful to see how your policy will be impacted by the XSS-blocklist.

This means that if you do setHTML("...", sanitizer: {}) you're only impacted by the XSS-blocklist. If you do setHTML("...") you get our more conservative "default" take.

Coupled with #229 I think this would provide all the building blocks we need.

annevk commented 5 days ago

3/4 are addressed by https://github.com/WICG/sanitizer-api/commit/7e2f1271e46e645a3ae00b86d79d05934a29c4c5 and 1 is noted. But 1/2 still need to be done.

And note that 4 was morphed into the clearly better removeUnsafe().