Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Created an isomorphic wrapper for DOMPurify #400

Closed
kkomelin opened this issue Mar 18, 2020 · 8 comments
Closed

Created an isomorphic wrapper for DOMPurify #400

kkomelin opened this issue Mar 18, 2020 · 8 comments

Comments

@kkomelin
Copy link

kkomelin commented Mar 18, 2020

Hey guys,

The issue is not typical, so excuse me for not following the issue template.

I don't have proper words to thank you for your work on the library. It's probably one of the most important projects in the JS ecosystem, even if some people don't know about it yet.

While working with DOMPurify in Next.js (with and without SSR), I noticed that it needs some additional initialization logic for server-side code (sort of a fake DOM tree). To simplify the initialization and make it universal on both frontend and backend, I've created an isomorphic wrapper https://github.com/kkomelin/isomorphic-dompurify

I would appreciate your feedback on the project and it would be an honor for me if it could give ideas on how to make DOMPurify itself even better.

Thanks,
Konstantin

@cure53
Copy link
Owner

cure53 commented Mar 18, 2020

Haha, this is cool, thanks for pointing this out :D

@kkomelin
Copy link
Author

@cure53 You're welcome.

@karlhorky
Copy link

karlhorky commented Mar 7, 2023

For usage of DOMPurify in Next.js Server Components without the wrapper package isomorphic-dompurify, here is a demo of a simple version:

Mainly the code is this:

import DOMPurify from "dompurify";
import { JSDOM } from "jsdom";

export default function Home() {
  return (
    <div
      dangerouslySetInnerHTML={{
        __html: DOMPurify(new JSDOM("<!DOCTYPE html>").window).sanitize(
          "<img src=x onerror=alert(1)//>"
        ),
      }}
    />
  );
}

There is also some needed webpack configuration to fix the issues with bundling jsdom and canvas, also described in the issue above.

@cure53 maybe this recipe above would be good to add to the readme for Node.js and Next.js users? I was looking for an example of how to use it with Node.js and ended up looking at the source of isomorphic-dompurify.

@kkomelin
Copy link
Author

kkomelin commented Mar 7, 2023

@karlhorky Thanks. If the webpack configuration is adjusted for better bundling of jsdom/canvas as you suggested, will isomorphic-dompurify suit you? Because it does pretty much the same things which you illustrated in your code example.

@karlhorky
Copy link

karlhorky commented Mar 7, 2023

If the webpack configuration is adjusted for better bundling of jsdom/canvas as you suggested, will isomorphic-dompurify suit you?

No, I personally think isomorphic-dompurify should be deprecated with a notice on how to achieve the same thing using the main dompurify library (3.5m weekly downloads vs 300k for isomorphic-dompurify).

I think this because:

  1. What happens if you're unavailable in the future to maintain the library?
  2. What happens if your supply chain security is not as strong as the dompurify library?
  3. Other security concerns about the wrapper package...

If the wrapper can be done with a few lines of code in a project, I think the wrapper package should not exist.

Alternative: it could be absorbed into the DOMPurify repo itself (eg. as a separate import path dompurify/isomorphic or separate official package eg. @dompurify/isomorphic) if @cure53 is willing to maintain that, so that it can be maintained and enjoy the security benefits of the more popular package / ecosystem.

@kkomelin
Copy link
Author

kkomelin commented Mar 7, 2023

@karlhorky Thank you for your opinion. I can't agree with it but I respect it.

  1. People use packages because they make people's work simpler. It doesn't really matter how much code is inside. There are some tiny packages in JS ecosystem which are popular enough.

  2. As for your security concerns, such as what happens if I'm unavailable, I can also address this question to any opensource project maintainer. if anything happens tomorrow with any of us, the community will pick the project up and create a fork.
    As for myself, I normally apply dompurify updates the same week they are released.
    As for other hypothetical security concerns which are not based on anything, let's leave them unaddressed.

  3. @cure53 and I already thought about merging the isomorphic-dompurify code into dompurify and decided not to proceed with it. But please let us know if you'd like to help with it.

@karlhorky
Copy link

1. People use packages because they make people's work simpler. It doesn't really matter how much code is inside. There are some tiny packages in JS ecosystem which are popular enough.
2. As for your security concerns, such as what happens if I'm unavailable, I can also address this question to any opensource project maintainer. if anything happens tomorrow with any of us, the community will pick the project up and create a fork.

Indeed, small packages + unavailable maintainers are not normally a problem - the community heals - but dompurify is a library that deals with security, so all security concerns are heightened with this.

@kkomelin
Copy link
Author

kkomelin commented Mar 7, 2023

@karlhorky ,

Indeed, small packages + unavailable maintainers are not normally a problem - the community heals - but dompurify is a library that deals with security, so all security concerns are heightened with this.

Makes sense. If you help dompurify work server-side out of the box, I will deprecate the isomorphic-dompurify project. No problem at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants