Add support for `DOMPurify` to the `RawHtml` component? about hydrogen-v1

[wizardlyhel]

Also my thought as well. Make RawHtml a client only component and use DOMPurify on its own should do just fine. DOMPurify itself is tiny: the weight is all in the JSDom.

[wizardlyhel]

DOMPurify requires a DOM to exist in order to sanitize a valid HTML string.

Hydrogen have several environments that we need to ensure it works within:

• worker (server side)
• node (server side)
• SSR pass (server side)
• RSC pass (client side)

Problem with the server side sanitization is that we don't have a DOM and we would need to create one with libraries such as jsDOM. This introduces many browser dependencies that the server environment may not support (ie. canvas is not supported)

Problem with client side sanitization is that our SSR pass will be different (due to no DOM so no sanitization) compare to what client component has generated (have DOM and can sanitize)

[wizardlyhel]

For now, we are going to remove RawHtml component.

We should revisit this another day.

A possible path we can approach. Implement a tokenizer/parser similar to html-parser-lite This package is only 25KB. However, we would need to modify it so that it returns html string. We can implement scanner to prevent tokenization of un-allowed tag or attributes.

[wizardlyhel]

Using DOMPurify package is a giant performance hit.

DOMPurify make use of jsdom - JSDom is a pure javascript implementation of a Javascript DOM element. This allows DOMPurify to run heuristics to remove harmful html.

However, we are looking at a significant bloat to our vendor.js ~ 4MB

Without DOMPurify

With DOMPurify

Second problem we have with DOMPurify is that it depends on JSDom which is written in commonjs. If we were to use this package all within server or all within client, it would have been fine. However, we are using it with RawHtml component which can be a server or client component and vite doesn't like that.

with or without ssr.noExternal

Additional problem with JSDom: triggers html security errors on its own

[frehner]

Strange, I wonder if it's because we're using isomorphic-dompurify instead of dompurify directly?

If we were to use dompurify in a client-only component, then we could use useLoadScript() like we do for other large libraries like model-viewer?

Also, dompurify itself has an ESM build, too: https://github.com/cure53/DOMPurify/blob/main/dist/purify.es.js

[wizardlyhel]

What have we tried:

• Add DOMPurify and jsDOM dependencies - exceeds worker limit of 1MB script (jsDOM adds 4MB)
• Make RawHtml a client only component - Can result in SSR and client render mismatch
• Use Cloudflare's HtmlRewriter and transform response on html selector detection - Doesn't have DOM node api to query inner nodes & won't work for RSC
  the ElementHandler’s element function returns the exact html node and we cannot search within that node .. for example, a typical html from admin would be

    <p style="color: red;">This is a test</p>
    <br/>
    <p style="blue">This is another test</p>

  What I can do with HtmlRewriter is that I can wrap that custom html in a html tag that the rewriter can listen on .. for example

  <div data-sanitize>
    <p style="color: red;">This is a test</p>
    <br/>
    <p style="blue">This is another test</p>
  </div>

  However the ElementHandler , in this case, gets the Element node for div[data-sanitize] . There is no api to query for nodes inside this node.
  I don’t want to html sanitize the whole document, I just need to sanitize the strings that I flag that needs to be sanitize
  Also .. this won’t work with React server components as it is not html syntax

[wizardlyhel]

Another attempted solution: Shopify/hydrogen#828

This is using a tiny parser to tokenize html string and run through clean out any tag or attributes that is not allowed. The allowed list is defined by DOMPurify. The config option of this method can only prevent even more tags or attributes to be remove.

[wizardlyhel]

@maxshirshin Supplied a working example of the Cloudflare worker sanitizing solution

https://gist.github.com/maxshirshin/06472e760ae65460f7201e0bd40830b5

However, this will not be able to sanitize an RSC response as it is not in html format

[cartogram]

For when we reviist this I came across this framework today: https://interweave.dev/

Just more food for thought vs something we'd actually use as I don't think it would solve the support the worker environment.

[markmcintyre]

Have you considered Markdown? Given the ubiquity and safety of it, this would likely be a popular and easy choice for Hydrogen users.