Mitigations for being unable to use a nonce

[alex-r89]

Hi there,

I had a read of this and it seems like I am unable to use a nonce for my style-src (Im using CSS in JS (styled-components)). I believe this is also the case for 'script-src' - im seeing the same error.

I was therefore wondering, what would be the "next best" values for these? If I have to use 'unsafe-eval' or 'unsafe-inline' for these to get around this, is there any point in me using this package?

Apologies for asking this here, its not really an issue.

Thanks

[SimeonGriggs]

This package is terrific, thanks for putting it together.

But additionally yeah I'd like to see handling for inline Scripts (such as pushing window.dataLayer events) unless you've got a workaround for this?

[trezy]

TL;DR

There's not a good option for implementing strong CSP on a Next.js application until we can solve #23993.

---

Yeah, I should probably add something about this to the README. Unfortunately, nothing has changed since this past June. We still don't have access to a nonce or hashes when rendering headers, which means we can't handle inline scripts in any significant way.

However, I'm trying to connect with the Next team to solve that problem. In the meantime, your options for strong CSP in a Next application are:

1. For the strongest CSP, put it behind a reverse proxy like Apache or nginx so you can you set your own headers.
2. Use next-safe. next-safe sets strong CSP headers for everything except for inline scripts and styles, which prevents a lot of issues that could occur. Because it doesn't handle inline scripts, however, it misses out on one of the most valuable pieces of setting a strong CSP.
3. Use a CSP <meta> tag, like @leerob has written about in the Next docs. This allows your application to set a stronger CSP than using next-safe, but it also exposes your application to MITM attacks from malicious scripts. If the user is using a browser extension with malicious code, for example, it could inject a script above the meta tag before the document is passed to the renderer, allowing that script to act like it came from your site and access domain-locked resources.

[nibtime]

Hi,

I played around with 'strict-dynamic' + hashes for static pages and Next 12, because it seems impossible to use nonces for static pages (build-time prerendered). I wrote a custom Head component that injects hashes of all Next.js framework scripts into a CSP meta tag in _document and then used edge middleware to inject CSP from pre-rendered meta tags into response headers before the page gets served.

I wrote a more detailed comment here: vercel/next.js#31402 (comment)

Code of my experiments: https://gist.github.com/nibtime/844b0286f3c73f30488118625d11a5d1

[trezy]

This is really interesting, @nibtime. We actually have #12 already for creating an edge middleware, we just haven't gotten around to doing it yet. I'm going to do a deeper dive into your code today to see what would be necessary to implement it directly into next-safe.

If you're game to pair on that work at some point, I'd love to do so. Feel free to join my Discord and hit me up.
https://discord.gg/k3bth3f

[nibtime]

Hi @trezy

If you're game to pair on that work at some point, I'd love to do so. Feel free to join my Discord and hit me up.

Sure, I'd love that. I also just started with the CSP topic, the code at this point is mainly a verification for my understanding around CSP and Next and as a PoC if 'strict-dynamic' was possible with static pages at all in a feasible way. I will join your Discord some time.

I created a fresh issue (#36) with details towards implementing this.

I think this could really benefit from being properly packaged up, documented and e2e tested within next-safe, as this isn't something you would want to handle at the project level. I am also not inclined to make a own package, as I personally wouldn't want to see 100 different libs handling the same already confusing topic :)