Allow a safer Content Security Policy when using Server Components

[Vinnl]

Goals

Be able to set a script-src Content Security Policy that does not include unsafe-inline.

Background

The docs provide an example Content Security Policy that sets script-src to 'self'. Unfortunately, when using Server Components (at least, I think those are the trigger, but it might be related to the app router or server-side rendering), Next.js appends a bunch of <script> tags to the DOM, presumably to stream the client components to the page?

Also note that MDN says:

Disallowing inline styles and inline scripts is one of the biggest security wins CSP provides.

Proposal

I think there are a couple of options ways to support streaming rendering without adding 'unsafe-inline':

• If Next.js can calculate the hashes of all scripts that could potentially get appended, it could make those available/automatically add them to the CSP header. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_hashes
• Generate a nonce for every request and make that available to the CSP headers/automatically add them.
• Append the scripts not as inline scripts but as separate external scripts? This probably has a performance impact.

[ciruz]

good idea
/subscribed

[will-btrt]

Subscribed! Our team is also having a massive pain with this. On doing some browsing around there seem to be some solutions to this but a lot of them seem outdated and / or quite hacky making them unideal. @danieltott from your issue I found here

[danieltott]

You currently can use a good, non-unsafe-inline CSP in Next 13 app directory/server components. The caveat being only on dynamic pages. This is because the solution involves using a nonce value, and by definition they need to be different on every page render, which is incompatible with static pages.

When the Next.js renderer renders a page with a nonce value in the script-src directive, it will grab that and insert it in to all <script>s that it inserts, both on the server and dynamically.

This can be done via middleware - see here for source, and here for a working example.

I would love to see a better solution for this though. Currently you need to add custom code to middleware, and, as stated above, this only works for dynamic pages.

• If Next supported some way to automatically calculate hashes as @Vinnl suggests, this would allow for a strong CSP on statically-generated pages, since the hash values would be known at build time.
• Next could also provide an easier way to go about adding a CSP and/or nonce values to an existing CSP. Perhaps in nextjs.config?
• At the very least, a better example in the docs could help

[leerob]

Hey folks, wanted to swing back here with an update. After digging through many different issues and discussions, I've made a new page in the documentation (PR) specifically for Content Security Policy and nonces. This docs page:

• Explains how to generate a nonce with Middleware
• Shows how to consume the nonce in a route with headers()
• Shows a complete CSP without needing to use any unsafe
• Shows how to ignore the nonce Middleware from running on prefetches / static assets

Further, we've patched some bugs and made improvements to nonce handling in Next.js that will be available in the latest canary version (for those of you time traveling from the future, upgrade to Next.js 13.5). We also updated the with-strict-csp example in the examples/ folder, which is backlinked from the new documentation page.

Really hope this helps out, thank you all 🙏 I'll be closing this discussion out. To continue the discussion, please go here.