sanitizer-api

By WICG

Sanitizer-api Alternatives

Similar projects and alternatives to sanitizer-api

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better sanitizer-api alternative or higher similarity.

sanitizer-api reviews and mentions

Posts with mentions or reviews of sanitizer-api. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-11-06.
  • Mastering DOM manipulation with vanilla JavaScript
    5 projects | news.ycombinator.com | 6 Nov 2023
    That entire post is poor.

    • “Using regular expressions”: it suggests that this approach is acceptable within its limits. It’s not at all. As a simple example, the expression shown is trivially bypassed by "…". This is why, unlike the post claims claims, using regular expressions for cleaning HTML is not a common approach.

    • (“Eliminating the script tags”: not sure quite why you’re against it, but I also want to grumble about using `[...scriptElements].forEach((s) => s.remove())` instead of `for (const s of scriptElements) { s.remove(); }` or even `Array.prototype.forEach.call(scriptElements, (s) => s.remove())`. Creating an array from that HTMLCollection is just unnecessary and a bad habit.)

    • “Removing event handlers”: `value.startsWith('javascript:') || value.startsWith('data:text/html')` is inadequate. Tricks like capitalising in order to bypass such poor checks have been common for decades.

    • “Retrieving the sanitized HTML”: you are now vulnerable to mXSS attacks, which undo all your effort.

    • “Elements and attributes to remove from the DOM tree”: this proposes a blacklist approach and mentions a few examples of things that should be removed. Each example misses adjacent but equally-important things that should be removed. You will not get acceptable filtering if you start from this approach.

    • “Simplifying HTML sanitization with external libraries”: this is pitched merely as easier, faster and cheaper, rather than as the only way to have any confidence in the result.

    • “Conclusion”: as I hope I’ve shown, “The DOMParser API is one tool you can use to get the job done right.” is not an acceptable position.

    Really, the article could be significantly improved by presenting it as what a common developer might think, and then scribbling all over the problematic things with these explanations of why they’re so bad, and ending with the conclusion “so: just use the DOMPurify library; consider nothing else acceptable”. (There have at times been a couple of other libraries of acceptable quality, but as far as I’m concerned, DOMPurify has long been the one that everyone should use. I note also that this article is talking about client-side filtration. I’m not familiar with the state of the art in server-side HTML sanitisation, where you probably don’t have an actual DOM; this is also a reasonable place to wish to do filtering, but the remaining active mXSS vectors might pose a challenge. I’d want to research carefully before doing anything.)

    I look forward to the Sanitizer API <https://wicg.github.io/sanitizer-api/> being completed and deployed, so that DOMPurify can become just a fallback library for older browsers.

  • 5 injection vulnerabilities hackers don't want developers to know about (and how to prevent them)
    3 projects | /r/node | 22 Jun 2023
    The upcoming Sanitizer API - kinda like a native DOMPurify that provides el.setHTML() and Document.parseHTML()
  • Google, Mozilla Close to Finalizing Sanitizer API for Chrome and Firefox Browse
    5 projects | news.ycombinator.com | 20 Oct 2021
    Seeing as [nobody seems to have brought it up to them](https://github.com/WICG/sanitizer-api/issues?q=sgml), I'm not surprised that they haven't addressed it.

    But, as always, specific & easy-to-use APIs are going to win out over more "fully general" ones. Are you suggesting that everybody learn DSSSL and write queries like

        ((match-element? nd '(section title))
    5 projects | news.ycombinator.com | 20 Oct 2021
    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. 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.

    Additionally, the Sanitize API does a much better job of handling contextual parsing then many other similar backend APIs. 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: https://wicg.github.io/sanitizer-api/#strings

    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.

    Personally, I would probably still stick with Nokogiri for my own applications, but I can see both sides of the trade-off.

    5 projects | news.ycombinator.com | 20 Oct 2021
    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: https://wicg.github.io/sanitizer-api/#strings

    This API is simply a DOM-based whitelist for preventing script execution coupled with a contextual parser. No more, no less. It doesn't solve every problem with accepting untrusted HTML, sure, but it's good enough for a wide variety of use-cases (One example that comes up frequently is embedded markdown, another good example is a mail client—both situations where formatted, user-controlled data is important). 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. (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)

  • A note from our sponsor - SaaSHub
    www.saashub.com | 29 Mar 2024
    SaaSHub helps you find the best software and product alternatives Learn more →

Stats

Basic sanitizer-api repo stats
5
213
4.9
about 21 hours ago

WICG/sanitizer-api is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.

The primary programming language of sanitizer-api is Bikeshed.

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com