Feature Request: DevTools warning and enforcement against static CSP nonces generated at build time

[Neizan93]

Hello,

I am a frontend developer. My team is currently implementing CSP with nonces. As per security standards, a nonce must be generated dynamically for every request, which I had successfully implemented. However, our frontend lead decided to generate the nonce statically during the build pipeline. This is the exact opposite of a secure CSP implementation.

Could you please implement a security mechanism to block or warn about pages that repeat the same nonce on every request? This would help developers like me force our teams to adopt the correct, secure solution.

Here is a proposal on how this could be approached at the browser engine level:

Problem Statement: Generating CSP nonces statically during the CI/CD build pipeline creates a false sense of security, entirely neutralizing the XSS mitigation that the CSP specification is designed to provide.

Proposed Solution: I propose implementing a strict security check within the browser engine to detect predictable, static, or heavily cached nonces. Specifically:

1. DevTools Violation: Trigger a severe security warning in the console if a page containing a CSP nonce is served with aggressive caching headers (e.g., missing Cache-Control: no-cache or no-store), as this inherently implies the nonce is being reused.

2. Enforcement: Introduce a mechanism to track nonce entropy or reuse across hard reloads for the same origin. If a static nonce is detected, the browser should disregard it, thereby blocking the inline scripts and forcing development teams to fix the implementation.

Impact: Implementing this strict validation at the browser level will force technical leads and engineering teams to adopt correct dynamic nonce generation strategies, eliminating "placebo" CSP implementations across the web.

[Jon]

Thanks for submitting an idea to the Mozilla Connect community! Your idea is now open to votes (aka kudos) and comments.

[glob]

CSP checks aren't part of DevTools itself; rather they are part of the engine that implements CSP.  I'll chat with that team, however I think it's unlikely this suggestion will be implemented.

> Implementing this strict validation at the browser level will force technical leads and engineering teams to adopt correct dynamic nonce generation strategies, eliminating "placebo" CSP implementations across the web.

You might gain support from your leads by referencing the specifications instead - https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/nonce

With attention to the definition of Nonce: "an arbitrary number that is used only once in a cryptographic communication".

> … our frontend lead decided to generate the nonce statically during the build pipeline. This is the exact opposite of a secure CSP implementation.

If your scripts are static you could use a "CSP hash" instead - this usually involves generating the hash during the build pipeline and using that in your CSP header directly.  Troy Hunt has a nice introduction from 2017 around this.

[freddyb]

Hi, thank you for recommending an improvement to Firefox. I like the idea, but there are some technical issues which may result in false positives that are hard to verify. I have seen hard-coded nonce values on pages that are purely static hosting, e.g., without any server part that is generating HTML dynamically. Reuse would be problematic in light of injections, but if the code is just static HTML then some other benefits of CSP might apply without requiring a host-based script-src directive.

Given the ambiguities when assessing the security of nonce reuse, I would consider it problematic to say that every reused nonce is immediately bad.

It could be a cool side project for learning - maybe in a browser extension?