Exploring the Origins
About a year ago, our company embarked on a journey to implement CSP throughout all our digital platforms. Each of these platforms was built using an express.js + react framework. In order to adhere to the guideline that "Each HTTP request must use a separate nonce," we decided to generate two nonces - one for the app chunk and one for the vendor chunk produced by webpack.
At that time, we believed this approach was set in stone until we ventured into using Next.JS for some recent projects. Unlike our previous setup, Next.JS functions with a singular nonce for every script or chunk it generates. The process involves creating a nonce in middleware and passing it to <NextScripts /> within the _document file. This deviation has left us feeling uncertain, especially when it appears that no one else seems troubled by this method. Considering the upward trend of Next.js in the industry, we reluctantly accepted the single nonce practice.
Recently, as we delved deeper into code splitting within our express apps, it has become evident that each chunk should ideally have its own unique nonce. This conflicts with the principles of Next.JS, prompting me to contemplate whether reverting back to our former stack might be necessary due to the paramount importance of CSP for our organization.
Raising Inquisitive Concerns
The following questions have emerged in light of this evolving scenario:
- Is it feasible for a nonce to be reused as long as it is dynamically generated at the server/middleware level before being sent to the scripts?
- Does Next.JS's limitation in accommodating multiple nonces signify a deliberate design choice that hinders its CSP compliance (thus rendering it unsuitable for those prioritizing correct CSP implementation)?
- When segmenting chunks into clusters, should each individual chunk within a cluster possess a unique nonce, or is it acceptable for the entire cluster to share a common nonce?