CSP without unsafe-inline & docusaurus-theme-classic

[bcaller]

docusaurus-theme-classic injects a script tag into the page.

This makes it difficult to apply a Content Security Policy without script-src 'unsafe-inline'. Is there a recommended way around this?

Things that could help are switching the injected tag into an external script file, or SHA384 hashing the script content on build and adding the hash to the CSP.

Anyway, just wondered if anyone has solved this before. There doesn't seem to be a nice plugin hook that would work both in dev server and in production builds where the script content can be inspected.

[slorber]

This script is inline because we need it to execute asap to avoid flash of unstyled content, notably reading the dark/light mode from localStorage before the UI prints anything.

If we moved this to an external resource, we'd have to block and to wait for it to download before the user sees anything, otherwise the UI would maybe first display the bad theme, and then the theme "gets fixed", producing bad blinking UX. For performance reasons it's much better to inline such scripts, and many other frameworks do the same. It's not just about the theme, but the announcement bar and the classes injected through data attributes too. All this needs to run as soon as possible.

I'm not an expert in CSP. Why do you need that "unsafe-inline" in the first place? Can you share an example of how to have an inline script, and yet make it pass your requirements?

[bcaller]

Thanks for the reply.

If you have Content-Security-Policy header with script-src 'self';, inline scripts will not execute - only those loaded as external scripts from the same origin will execute.

unsafe-inline would allow all inline scripts. To provide a layer of defence against XSS attacks I'd prefer to avoid this.

To avoid unsafe-inline you can include the hash of the inline script as described at https://content-security-policy.com/hash/

<script>doSomething();</script> -> SHA256 of content inside script tags, output as base64 -> RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc= -> CSP script-src 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc=';

Described at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_inline_script

Disallowing ... inline scripts is one of the biggest security wins CSP provides.
Allowing all inline scripts is considered a security risk, so it's recommended to use a nonce-source or a hash-source instead

It's also possible to use a nonce, but nonces can only be used once i.e. needs to be regenerated on every HTTP request, which means they aren't suitable for statically built sites.

I guess I could make some tool which runs over the built HTML and calculates the hashes on production builds, but not sure how to do that for the dev server build.

[slorber]

And how would you exploit XSS on a Docusaurus site in the first place?

That seems quite unlikely to happen considering pages are static and all inserted scripts are injected at build time. The only way probably involves hacking the developer or using a CDN Middleware, in both cases this can be much more harmful?

[bcaller]

Yes, it would be due to other elements or scripts added to the page.

[slorber]

Sorry but I don't understand your response.

Can you show an example exploit, as proof that it's worth it for us to invest time in solving this problem? My goal here is to avoid spending time solving theoretical-only problems.

---

To avoid unsafe-inline you can include the hash of the inline script as described at content-security-policy.com/hash

We don't control your server CSP response headers, but you do. Considering the inline script should be the same for all pages, what prevents you from computing the hash manually and hardcoding it as a response of your web server CSP?

I guess I could make some tool which runs over the built HTML and calculates the hashes on production builds

Do you really need to make a tool? We don't update that script often and you could just copy/paste the script string manually by running a code snippet on your landing page console?

const scriptContent = document.querySelector("body > script").innerHTML

async function computeScriptCSP(content) {
  const msgUint8 = new TextEncoder().encode(content); 
  const hashBuffer = await window.crypto.subtle.digest("SHA-256", msgUint8);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  const hashHex = hashArray
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
  return hashHex;
}

computeScriptCSP(scriptContent).then((digestHex) => console.log(`sha256-${digestHex}`));

(inspired from https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest#converting_a_digest_to_a_hex_string)

but not sure how to do that for the dev server build

Why do you need a CSP for the dev server in the first place?