Element: setHTML() method on MDN
60 points by freddyb
60 points by freddyb
This is ready for testing in Firefox Nightly.
The method provides an xss-safe alternative to innerHTML and I would love to hear what you think about the default list so far.
In particular, I am really interested in hearing what you think it should and shouldn’t filter and why.
Here or in https://github.com/WICG/sanitizer-api/issues
Does it strip style attributes? How about class="..."?
I always worry about attacks like this:
<a href="https://phishing-site.com/"
style="position: absolute; top: 10px; left: 10px">
Login</a>
Where this is intended to appear as if it's part if the official site UI.
If the site uses something like Tailwind the class attribute can open up the same hole.
The current default configuration is at https://wicg.github.io/sanitizer-api/#built-in-safe-default-configuration
As far as I can tell it disallows all forms of styling by default, but it’s quite large and I’m on my phone.
Yep. The default values disallow a lot of things to prevent attacks that build on invoking a framework functionality through non-standard things (so-called script gadgets). It’s rather strict, but I hope people will tell us if it’s desirable vs unexpected.
Please give it a try.
We should really make that list easier to read and when moving the Sanitizer API into the HTML specification we will probably have to replace the JSON anyway.
Maybe MDN should also have some kind of nice representation of the default configuration.
it looks like a's rel is allowed? Probably safe in most cases but there are authentication systems built around it.
If someone used it for comments on their site, it would allow for impersonation attacks against approaches like IndieLogin
Considering its use for making claims about an outgoing relation to the current document / article, it might be best to not support rel entirely
I think you have a point. Do you want to file an issue?
This is good and I’m glad they’re working on it but also I wish they would put more love into iframes. Iframes are an actual security boundary and they are almost perfect except you need to use JS to set the height. If they would just let us do that with a security attribute, it would be the perfect solution to tons of use cases.
Huge +1 to that!
The <iframe sandbox= attribute is completely load-bearing right now. It's painfully hard to find robust documentation for it, especially covering how it might differ between different browsers.
Auto-resizing iframes without all of those horrible postMessage tricks would be wildly useful.
What is the point of this vs trustedtypes?
Slightly different use cases. Trusted Types requires you to write a policy and apply a CSP, but it can also ensure consistency by relying on the CSP being applied to the whole document. It crucially also doesn’t come with an HTML sanitizer. You need to figure out how some HTML becomes trusted by yourself.
This here, gives control at the insertion level. Ideally, a smaller website can rewrite all innerHTML into setHTML and then be done with it.
Having a default sanitizer is a good move. Will we be able to use that with trust types as well?
You can use setHTML/parseHTML with normal strings even when you have a trusted types policy.
I don’t like the name setHTML(), that sounds like it’s supposed to interpret HTML just like .innerHTML = would. I don’t know what a better name would be, though.
Truth be told: It’s not exactly like innerHTML. It is the default, everyone should use it, safe alternative to setHTMLUnsafe()
The difference between these two unsafe variants is that the newer one will parse declarative shadow DOM.
Maybe that explains the name :)