React 18: bootstrapScriptContent escapes HTML so quotes can’t be used

[calebmer]

If you use the bootstrapScriptContent option of renderToPipeableStream() to provide hydration data (as recommended in the <script> upgrade guide) with JSON.stringify() it doesn’t work because React escapes HTML characters in bootstrapScriptContent like quotes. I’ve worked around this by using backticks to deliniate strings.

What’s the correct thing to do here?

react/packages/react-dom/src/server/ReactDOMServerFormatConfig.js

Lines 99 to 105 in cdb8a1d

	if (bootstrapScriptContent !== undefined) {
	bootstrapChunks.push(
	inlineScriptWithNonce,
	stringToChunk(escapeTextForBrowser(bootstrapScriptContent)),
	endInlineScript,
	);
	}

[salazarm]

@sebmarkbage @acdlite Is the escapeTextForBrowser usage here intentional? I think it might make sense not to escape here since it's not HTML and its supposed to be javascript here.

[sebmarkbage]

Yea it's probably not the correct escape. We should escape somehow though because </script> and such content shouldn't be allowed. Not escaping random JSON that might contain user generated strings would be a bad and common security issue.

It's a common security issue in many non-meta frameworks.

cc @sophiebits knows the exact pattern needed.

If we can't make it generic we should at least rename it "dangerous" and describe how to escape any JSON content someone might add there.

[sophiebits]

See the update at the end of my post here: https://sophiebits.com/2012/08/03/preventing-xss-json.html. Basically replacing the s in </script with \u0073 (or S with \u0053). Make sure to match the pattern case-insensitively.

It's security-safe (to my belief) but note that this technically can change the meaning of a script with a tagged template literal since the raw text is available, but I doubt that would come up in practice so it's probably fine.

The only other ideas I have are having the script encoded in some fully out-of-band way like a base64 data URI or putting the whole script in a string and then eval-ing it (both of which are weird for CSP).

[sebmarkbage]

@devknoll @timneutkens What does Next.js do to escape JSON? Presumably that has received enough exposure.

[sophiebits]

For JSON you only need to escape / as \/ (many JSON encoders do this automatically).

[timneutkens]

This is what we have in Next.js to escape JSON:
https://github.com/vercel/next.js/blob/5f4947e5a2c75099f7466a6ba8274d8ab4240e6c/packages/next/server/htmlescape.ts#L14-L16
https://github.com/vercel/next.js/blob/canary/packages/next/pages/_document.tsx#L817

[tranvansang]

This is blocking me from the upgrade to react 18.

How about optionally accepting an object with __htlm key and leave the responsibility to the user?

{
  bootstrapScriptContent: {
    __dangerouslySetInnerHTML: 'window.__BOOTSTRAP_REACT_APP__("complex inline ssr data")`
  }
}

With react 17, I used serialize-javascript to serialize the ssr data without any problem.

[sebmarkbage]

@sophiebits I found this little tidbit while reading the spec. w3c/html#1617

I'm not sure you can use that to inject new scripts but you can certainly cover up future scripts or content and break the page.

I think it's probably ok if you also encode the s in <script.

[sebmarkbage]

This API only really promises to encode valid JS into HTML. It doesn't promise to turn JSON into JS. In practice anyone using this to inject JSON will need to use another tool to escape JSON into valid JS since we can't parse out the JSON parts from arbitrary JS anyway.

So it's not super critical that we cover all cases because they'll be covered by that encoding anyway. Our escaping is more of a convenience and extra layer of protection.

Edit: Actually because of https://github.com/tc39/proposal-json-superset you probably don't need to escape it in modern browsers. Although many probably will keep doing it as a precaution. You also have to consider "__proto__" properties in JSON anyway.

Escaping the s in </script> and <script> to \u0073 as well as the upper-case version is probably sufficient.

[sebmarkbage]

I think we're just going to deprecate XHTML support therefore I don't think ]]> is a sequence of concern. Correct me if I'm wrong.

Additionally, some escape <!-- and --> in JSON because they can switch the parsing modes. However, since we escape all <script> and </script> in the entire script and not just the JSON part of it, I don't think that concern applies here.

The reason we wouldn't escape them is because the clever hack doesn't work on these while it remains valid JS.

[gnoff]

@calebmer should be available in the next minor

[gaearon]

Fixed in 18.1.0.