globby VS DOMPurify

Compare globby vs DOMPurify and see what are their differences.

DOMPurify

DOMPurify - a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks. Demo: (by cure53)
Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
globby DOMPurify
7 40
2,455 12,636
- -
6.2 8.5
about 2 months ago 7 days ago
JavaScript JavaScript
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

globby

Posts with mentions or reviews of globby. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-12-22.

DOMPurify

Posts with mentions or reviews of DOMPurify. 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
    You mean from this article "Sanitize HTML strings"? https://phuoc.ng/collection/html-dom/sanitize-html-strings/

    Yeah, that article really shouldn't imply that sanitization is "that easy". It does at least mention https://github.com/cure53/DOMPurify at the end but it should LOUDLY argue against attempting to write this particular thing yourself and promote that exclusively in my opinion.

  • Crafting a Dynamic Blog with Next.js 13 App Directory
    3 projects | dev.to | 1 Sep 2023
    It is highly recommended to use an XSS Sanitizer like DOMPurify to sanitize HTML and prevent XSS attacks. For Next.js projects, which prominently feature server-side rendering, Isomorphic DOMPurify is especially valuable. It offers a seamless sanitization process across both server and client, ensuring consistent HTML sanitization in environments like Next.js where a native server-side DOM isn't present.
  • 5 injection vulnerabilities hackers don't want developers to know about (and how to prevent them)
    3 projects | /r/node | 22 Jun 2023
    body, input.value property, or body are all different). If you need to insert untrusted input into raw HTML, use a well-tested sanitizer such as DOMPurify.

    Setting a strong Content Security Policy without unsafe-inline or unsafe-eval in the script-src or default-src directives is an effective defense-in-depth) measure to prevent modern browsers from executing attacker code even if the attacker is able to insert </code> elements into the page.</p> <p><strong>3. HTTP API injection</strong></p> <p>RESTful APIs, GraphQL, and other HTTP-based APIs are ubiquitous. When a web application makes an API call to another service, injection vulnerabilities are possible when that request includes untrusted input.</p> <p>Consider a contrived example in which a web app integrates with a payments service that has a REST API endpoint for creating a subscription: <code>POST /subscriptions/{product_id}?price_usd=<price></code> where <code>price_usd</code> is optional, and a pre-configured price is used if omitted. If an attacker controls the value of <code>product_id</code> and passes a value of <code>desired_product_id?price_id=0</code>, the web app would end up making a request to <code>POST /subscriptions/desired_product_id?price_id=0</code>, which would allow the attacker to sign up for a free subscription.</p> <p>In JavaScript, the standard way to sanitize untrusted inputs in URL paths is <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent"><code>encodeURIComponent</code></a>, which replaces problematic characters such as <code>?</code> and <code>/</code> with safe percent-encoded sequences. When inserting untrusted input into URL query parameters, <a href="https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams"><code>new URLSearchParams(queryParams)</code></a> provides a convenient, safe interface for building a query string from a JavaScript object of key-value pairs.</p> <p><strong>4. Shell injection</strong></p> <p>Backend APIs sometimes need to execute external commands on the machine where they run. Consider an API that performs <a href="https://en.wikipedia.org/wiki/WHOIS">WHOIS</a> lookups for a requested domain by executing the <code>whois</code> command locally.</p> <p>Consider the following <strong>vulnerable</strong> Node.js code:</p> <pre><code>const whois = child_process.execSync(`whois ${whoisRequest.domain}`); </code></pre> <p>If an attacker can pass the domain <code>reddit.com && rm -rf /</code>, the backend will execute the command <code>whois reddit.com && rm -rf /</code>. The <a href="https://nodejs.org/api/child_process.html#child_processexecsynccommand-options"><code>child_process.execSync</code></a> function passes the command string to the shell (<code>/bin/sh</code> by default on Linux), which parses <code>&& rm -rf /</code> as a subsequent command to wipe the filesystem.</p> <p>To avoid this issue, <strong>never pass untrusted input to a shell</strong>. Instead, use an interface such as <a href="https://nodejs.org/api/child_process.html#child_processexecfilesyncfile-args-options"><code>child_process.execFileSync</code></a> that executes a specific binary (which shouldn't be a shell!) and passes arguments <em>as an array</em>:</p> <pre><code>const whois = child_process.execFileSync("whois", [whoisRequest.domain]); </code></pre> <p>Now, even if the user passes a domain <code>reddit.com && rm -rf /</code>, that entire string will be passed as the command-line argument to <code>whois</code>, which will exit with an error but will not cause any harmful side-effects. Perhaps an even better solution would be to use a library to perform WHOIS queries without needing to execute a separate command.</p> <p>Astute readers may point out that validating the domain against a regex would also likely prevent shell injection in this case. However, avoiding the possibility of shell injection by using a safe interface that keeps untrusted input away from a shell's command parser is a more robust solution that avoids shell injection in all cases.</p> <p><strong>5. Path traversal</strong></p> <p>Finally, a path traversal vulnerability arises when an untrusted input is inserted into a filesystem path, which can cause the wrong file to be read or even written. Consider a backend API that reads a file at the path <code>/teams/${team_id}/${report_name}.csv</code>. If an attacker controls the value of <code>report_name</code> but not <code>team_id</code>, they could pass a <code>report_name</code> of <code>../other_team_id/private.</code> This would cause the file <code>/teams/team_id/../other_team_id/private.csv</code> (resolved to <code>/teams/other_team_id/private.csv</code>) to be read, leaking data from a different team.</p> <p>To avoid path traversal vulnerabilities, <strong>never use untrusted input in file or directory names</strong>. It's safest always to control the names of files and directories, including IDs that you generate and control (e.g., UUIDs, KSUIDs, etc.). If the name of a file or directory absolutely <em>must</em> be derived from untrusted input, consider hashing it (e.g., using SHA-256) or at least encoding it into a format that doesn't include dots or slashes (e.g., <a href="https://datatracker.ietf.org/doc/html/rfc4648#section-5">URL-safe base64</a>).</p> <p>​</p> <p>Know of good Node.js libraries for avoiding injection vulnerabilities? Let folks know in the comments!</p> </div><!-- SC_ON -->

  • Six security risk of user input in ruby code
    2 projects | dev.to | 11 Apr 2023
    If you're using an external view engine, or a javascript framework like react in addition to your ruby backend, you can rely on similar sanitization methods like the DOMPurify library.
  • Wat
    5 projects | news.ycombinator.com | 29 Mar 2023
    You shouldn't roll your own for this. From what I've had to do web-wise, here's a few tools.

    First, for the APIs, you need documentation: https://swagger.io/

    From which you can generate JSON schemas and use those to validate in the browser and on the backend. https://www.npmjs.com/package/jsonschema

    As well you should be writing a few more schemas for your application state and leverage the regex validation of your input components...

    Speaking of which, you also need to sanitize out some potentially nasty input. https://www.npmjs.com/package/dompurify

    Obviously this isn't everything and not perfect, but a lot of this tedium can be automated away if you have a few good examples of the happy path and some basic tests in place to prevent quick and dirty changes from poking holes in these layers.

  • Alternatives to dangerouslySetInnerHTML
    2 projects | /r/reactjs | 6 Mar 2023
    Use DOMPUrify. That plus dangerouslySetInnerHTML and you're good to go.
  • Improving Render Performance in React
    3 projects | dev.to | 21 Nov 2022
    element. Note that using dangerouslySetInnerHTML may leave your site vulnerable to XSS attacks. In order to mitigate this risk, we need to sanitize the HTML before we inject it. We'll use DOMPurify for that task. import React, { Component } from 'react'; import marked from 'marked'; import * as DOMPurify from 'dompurify'; class UserProfile extends Component { constructor (props) { super(props); } render () { const { userId, name, skills = [] } = this.props; return ( {name} ({userId}) Skills {skills.map((skill) => ( {skill.name} ))} ); } } Enter fullscreen mode Exit fullscreen mode To recap, our process is: Parse the skill description markdown to HTML Sanitize the HTML Inject the HTML into a element If we think through this process in the context of the component render cycle, we can see how it could have a negative effect on performance: Perform two potentially expensive tasks in series (markdown parsing and HTML sanitization) Perform those tasks in a loop, which is also executed in series Repeat every time the component renders We can't do much about the first and second issues — we have to parse the markdown, sanitize the resulting HTML and render it — but we can avoid the third issue. Why render if nothing has changed? Here is an updated version of the previous example that uses shouldComponentUpdate to block the component from rendering unless the userId prop has changed: import React, { Component } from 'react'; import marked from 'marked'; import * as DOMPurify from 'dompurify'; class UserProfile extends Component { constructor (props) { super(props); } shouldComponentUpdate (nextProps) { return nextProps.userId !== this.props.userId; } render () { const { userId, name, skills = [] } = this.props; return ( {name} ({userId}) Skills {skills.map((skill) => ( {skill.name} ))} ); } } Enter fullscreen mode Exit fullscreen mode We're comparing the userId prop because it's a simple equality comparison that will tell us when the user has changed. You might be tempted to try to perform a deep equality comparison of the skills array instead, but that will likely create a worse performance issue than the one we're trying to solve. shouldComponentUpdate is intended to be used for performance optimization but should be used carefully and sparingly. Blocking a component from rendering can cause bugs in descendant components that can be difficult to fix, and there are usually better ways to improve performance. Reducing the rendering workload In the previous example, we tried to mitigate a potential performance problem by blocking a component from rendering. That was the wrong solution to take because it didn't address the real problem. The real problem isn't that we're allowing the component to render when it doesn't have to, it's that we're doing too much work in the render cycle. Therefore, the correct solution is not to block rendering entirely, but to reduce the amount of work we do while rendering. Option 1: Store preprocessed data on state One way of reducing the workload is to run the expensive process only when inputs change and store the results on state. This is simple and doesn't interfere with the render cycle. It works equally well in both class and functional components. Class component The following example updates our previous examples to preprocess the user's skills and store them on state, instead of reading directly from props in the render cycle. The preprocessing logic has been moved into the processSkills function, which is called in two places: componentDidMount, where it will run before the initial render; and componentDidUpdate, where it will run when the value of the userId prop changes. If the component renders for any other reason, it will continue to use the preprocessed data from state at no additional cost. import React, { Component } from 'react'; import marked from 'marked'; import * as DOMPurify from 'dompurify'; const processSkills = (skills = []) => { return skills.map((skill) => ({ ...skill, htmlDescription: DOMPurify.sanitize(marked.parse(skill.description)), })); }; class UserProfile extends Component { constructor (props) { super(props); this.state = { processedSkills: [], }; } componentDidMount () { this.setState({ processedSkills: processSkills(this.props.skills), }); } componentDidUpdate (prevProps) { if (this.props.userId !== prevProps.userId) { this.setState({ processedSkills: processSkills(this.props.skills), }); } } render () { const { userId, name } = this.props; const { processedSkills = [] } = this.state; return ( {name} ({userId}) Skills {processedSkills.map((skill) => ( {skill.name} ))} ); } } Enter fullscreen mode Exit fullscreen mode Functional component (hooks) The functional component produces the same result as the class component, but is more concise. The useEffect hook calls processSkills with the skills array from props when the value of the userId prop changes. The resulting array is stored on state and used to render the skills list. import React, { useState, useEffect } from 'react'; import marked from 'marked'; import * as DOMPurify from 'dompurify'; const processSkills = (skills = []) => { return skills.map((skill) => ({ ...skill, htmlDescription: DOMPurify.sanitize(marked.parse(skill.description)), })); }; const UserProfile = (props) => { const { userId, name, skills = [] } = this.props; const [ processedSkills, setProcessedSkills ] = useState([]); useEffect( () => setProcessedSkills(processSkills(skills)), [userId] ); return ( {name} ({userId}) Skills {processedSkills.map((skill) => ( {skill.name} ))} ); } Enter fullscreen mode Exit fullscreen mode Option 2: Memoize preprocessed data Another option is to memoize (not memorize) the results of the process. Memoization is a form of in-memory caching. We're only going to discuss this in the context of functional components where we can use the useMemo hook provided by React, but you may be able to achieve similar results in a class component using a third-party helper. In this example, the useMemo hook is called on every render. On the initial render and any time the userId prop is updated, useMemo returns the result of calling processSkills with the skills array. If the userId prop hasn't changed since the last render, useMemo returns the previously cached result. import React, { useMemo } from 'react'; import marked from 'marked'; import * as DOMPurify from 'dompurify'; const processSkills = (skills = []) => { return skills.map((skill) => ({ ...skill, htmlDescription: DOMPurify.sanitize(marked.parse(skill.description)), })); }; const UserProfile = (props) => { const { userId, name, skills = [] } = this.props; const processedSkills = useMemo( () => processSkills(skills), [userId] ); return ( {name} ({userId}) Skills {processedSkills.map((skill) => ( {skill.name} ))} ); } Enter fullscreen mode Exit fullscreen mode Which option should I choose? If you're working with class components, I suggest preprocessing and storing data on state unless you think you have a strong use case for integrating a memoization helper (e.g. you need memoization throughout your app, not just in one or two places). In functional components, memoization offers the same benefit as preprocessing and storing the result on state without having to maintain state. However, it isn't guaranteed to be predictable. From the React docs: You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance. Storing data on state may be a better choice if the predictability of your performance optimizations is critical to your application. In many, if not most cases it won't be critical, and memoization will likely be the cleanest and simplest way to improve render performance.
  • Ask HN: Is it time for a new Storybook?
    4 projects | news.ycombinator.com | 19 Nov 2022
    Coupled with DOMPurify [0], it helps much to simplify the messy JavaScript, HTML. Yin [1] has book on that.

    [0]:https://github.com/cure53/DOMPurify

  • How I Made My Portfolio with Next.js
    14 projects | dev.to | 13 Oct 2022
    You need to install dompurify. DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML and SVG. This is the optional step.
  • Storing Rich Text from ReactJS Editor
    2 projects | /r/PostgreSQL | 1 Aug 2022
    I'm assuming JavaScript (or TypeScript) is the desired language here as you're using React. DOMPurify would work client-side and also with Nodejs if you have a JS backend that you use to to interact with Postgres (which would naturally be safer place to handle the sanitation compared to client-side). To be extra cautious, sanitising the user input both when writing and printing would be done

What are some alternatives?

When comparing globby and DOMPurify you can also consider the following projects:

sanitize-html - Clean up user-submitted HTML, preserving whitelisted elements and whitelisted attributes on a per-element basis. Built on htmlparser2 for speed and tolerance

js-xss - Sanitize untrusted HTML (to prevent XSS) with a configuration specified by a Whitelist

HtmlSanitizer - Cleans HTML to avoid XSS attacks

xss-filters

Next.js - The React Framework

isomorphic-dompurify - Use DOMPurify on server and client in the same way

Retire.js - scanner detecting the use of JavaScript libraries with known vulnerabilities. Can also generate an SBOM of the libraries it finds.

Themis - Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

SuperTokens Community - Open source alternative to Auth0 / Firebase Auth / AWS Cognito

Thymeleaf - Thymeleaf is a modern server-side Java template engine for both web and standalone environments.

marked - A markdown parser and compiler. Built for speed.

prosemirror-schema-basic - Basic schema elements for ProseMirror