The Sanitizer API is a browser-provided implementation for the same problem DOMPurify tackles. Very nice to see this, for performance and maintenance benefits.
Decades of “solutions” and still MITRE rates this as top 2 / top 1 most dangerous and common vulnerability. I firmly believe this should become the browser’s responsibility.
Disclaimer, I’m quoted in the article and author of the spec :-)
Wouldn’t this create a false sense of security? Surely my browser validates an input of type “email” and warns me when the value is malformed, however, nothing stops me from manually passing an invalid e-mail-address directly via POST, most simply by replacing the input type with “text”, unless there is also server-side validation.
I expect this to be used less on content sent from a client to a server, but rather in reverse, content sent from a server to a client. For example, a dynamically fetched comment on a blog post is injected into the DOM after passing through the Sanitizer API. That is, the string value in the database is untrusted.
Of course, you could attempt to make it trusted by passing it through the Sanitizer API before even storing in the database through client side manipulation of the form, but that leads to your very concern as it could be bypassed. Run it through the Sanitizer both times? Submission and display?
The Sanitizer API is a browser-provided implementation for the same problem DOMPurify tackles. Very nice to see this, for performance and maintenance benefits.
MDN has documentation on what the API looks like currently, though it is in draft stages. Here is the specification itself.
No, why blink? I loved you blink, back in 1999. We’ll never forget you <3
What I want is the
<hype>tag again.The current MDN documentation is outdated. The latest API will not return strings.
The article implies that React does this, as well. Do you know whether that’s the case?
Yay, yet another browser API for something that has been solved by JS.
Decades of “solutions” and still MITRE rates this as top 2 / top 1 most dangerous and common vulnerability. I firmly believe this should become the browser’s responsibility.
Disclaimer, I’m quoted in the article and author of the spec :-)
I trust that there are some really good reasons. What troubles me is the growing browser spec, is all.
This but unironically. It’s good to be able to do more things without running JS.
Has it, though? The current solutions depend on irregularities of their implementation. Plus, this runs at native speed.
Wouldn’t this create a false sense of security? Surely my browser validates an input of type “email” and warns me when the value is malformed, however, nothing stops me from manually passing an invalid e-mail-address directly via POST, most simply by replacing the input type with “text”, unless there is also server-side validation.
I expect this to be used less on content sent from a client to a server, but rather in reverse, content sent from a server to a client. For example, a dynamically fetched comment on a blog post is injected into the DOM after passing through the Sanitizer API. That is, the string value in the database is untrusted.
Of course, you could attempt to make it trusted by passing it through the Sanitizer API before even storing in the database through client side manipulation of the form, but that leads to your very concern as it could be bypassed. Run it through the Sanitizer both times? Submission and display?
Sanitizing SVGs will be useful