You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Introduce Sanitizer.default() that returns the configuration we want setHTML() to use when no configuration is provided.
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.
new Sanitizer() now represents an empty policy. So if you pass that to setHTML() you only get the XSS-blocklist impacting you.
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.
The text was updated successfully, but these errors were encountered:
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:
Sanitizer.default()
that returns the configuration we wantsetHTML()
to use when no configuration is provided.setHTML()
'sSetHTMLOptions
'ssanitizer
default to "default
" rather than{}
.setHTMLUnsafe()
will continue to default to{}
. "default
" here is an enum value that meansSanitizer.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.new Sanitizer()
now represents an empty policy. So if you pass that tosetHTML()
you only get the XSS-blocklist impacting you.get()
andgetUnsafe()
.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 dosetHTML("...")
you get our more conservative "default
" take.Coupled with #229 I think this would provide all the building blocks we need.
The text was updated successfully, but these errors were encountered: