Plugin usage with blitz cache

[paspv]

Hey, I have a question regarding the usage of this plugin in combination with the blitz static page caching plugin.
When using the plugin with blitz, the nonces get cached. To my understanding, this pretty much defeats the purpose of nonces all together, since the nonce will be the same across multiple page loads, so I was wondering if there is an intended solution to this.

Everything else is working great so far, thanks for your work.

[cloudgrayau]

Hey, thanks for raising this — you're right, and it's a good catch.

You're correct that caching the nonce undermines the core security property of nonce-based CSP. Since the nonce ends up baked into the static HTML, it's no longer a secret — an attacker can read it straight from the page source and reuse it on an injected script tag, which the browser will then allow.

That said, it's worth noting this isn't quite as bad as having no CSP at all. A nonce-based policy still blocks 'unsafe-inline' by default, so even with a stale/cached nonce, you're still protected against the most common XSS payloads (plain injected <script> tags with no nonce, onerror=/onclick= handler injection, javascript: URIs, etc). What you lose protection against is a targeted attacker who specifically reads the cached nonce and crafts their payload to match it. So it's "better than nothing," just not as strong as a properly working nonce.

The tricky part is that Blitz's whole design is to skip PHP execution entirely on cached hits, so there's no way to generate a fresh nonce per request within Craft for those pages — by the time Blitz serves the cached file, PHP isn't in the picture anymore.
A couple of options as I see it:

• Hash-based CSP ('sha256-...') works well for inline scripts with static, predictable content, since the hash stays valid regardless of caching. This won't help if you have inline scripts with per-request random/dynamic content though, since the hash would change every time.
• A layer above the cached content that injects a fresh nonce per request (e.g. an Nginx sub_filter rule or similar, substituting a placeholder nonce in the cached HTML with a real one on the way out, and setting the matching CSP header at the same time) would properly fix this. I haven't fully scoped out how involved this would be to build/support though, and it's a server-level concern rather than something configurable purely through Craft/plugin settings — so it may end up being something I document as a recommended pattern rather than ship as a built-in feature.

For now, I'd suggest using hash-based sources where your inline scripts are static, and being aware of the limitation for anything dynamic. I'll keep this issue open as something to explore further down the track.

[paspv]

Hey, thanks a lot for answering my question - sadly hash-based CSP is not really an option for my particular use-case, so I will probably have to go with the second option, but I'll have to evaluate first. :)