Well, it's a good thing we're not talking about DOMPurify, because the spec we're talking about (the Sanitizer API), has lots of context information and does not provide a string -> string API: Personally, I would probably still stick with Nokogiri for my own applications, but I can see both sides of the trade-off. The downsides, of course, are those associated with any thick-client/thin-server API design-more logic on the front-end means more logic to reimplement for different consumers.
What happens when you parse an HTML fragment assuming it will live in a `div`, and then it actually get inserted into a `table` cell? The spec goes into this is more detail here:
#LEGACY CONTROLS WORD DATE PICKER CODE#
Additionally, you get to use the exact same code that the browser is ultimately using to parse the HTML, so a browser parsing bug, spec nuance, or un-specced legacy behavior that your backend developer didn't consider don't turn into serious security flaws.Īdditionally, the Sanitize API does a much better job of handling contextual parsing then many other similar backend APIs. The benefit of doing this client-side instead of server-side is that you can stay up to date with any changes that the client may make to how it's processing HTML that may have security implications.
0 kommentar(er)
