Static styles injected by Angular during build time causes CSP violation

Question

I am working on a Angular 18 project. My org has the strict CSP policy and no unsafe-inline is allowed. As documented by Angular here, while rendering the index.html, I generate a nonce per request when my server renders index.html and update it in <app-root ngCspNonce="">. This nonce, apparently, is then propagated by Angular in all the <scripts> or <styles> created at run time.

However, there are many styles (precisely 3 tags and quite huge) generated by Angular (even with inlineCritical: false) at build time. These are static in the dist generated by Angular at build time itself. It seems that the ngCspNonce attribute has no impact on these style. As a result, these style mark CSP violation at runtime.

Interestingly, if I keep a static ngCspNonce beforehand in my code, then at the build time that nonce is also copied to injected styles in the generated dist. However, that is of no use, as the nonce is supposed to be generated by server per request.

My Questions:

1. Is it correct that ngCspNonce do not apply to these static build time styles. My research says Yes. If so how are they propagated when the nonce is present at build time. Why Angular do not add/update nonce to those tags at runtime like it does for other dynamically generated tags (As per the documentation)
2. What is the way to handle these build time style tags (or script tags if angular might generate any) against the CSP. Should I be rewriting these tags again at every request.

As I said these styles are huge, generating a one time hash also doesn't seem feasible.

Would like to hear the thoughts on how this is being done for enterprise apps out there.

P.S: To my surprise, I am writing nonces in 3 tags from my server. All three of them land in the browser with the nonce included. Still, one of them is flagged for CSP violation. I am not sure, what might be the reason.

Answer 1

Well, this took me sometime but finally I have been able to figure out few concepts about Angular production handling of CSP and made my app CSP complaint without `unsafe-inline` using a nonce per request based approach.

In short, when you run Angular for production build with full optimization features (no inlineCritical:false), Angular does the following:

1. Generates few inline `<style>` tags and host them at the top of the html page.

2. Generate a <link> tag for loading styles at run time in an async manner to minimise FOUC.

Now, the first point will cause you CSP issues due to inline-style violation. What is interesting is, the second point will throw a script-src violation.

This is what was the original pain point for me. No visibile <script tag or inline scripts handler, still the script-src violation.

The reason for this is that the <link> in the second point contains an onload handler. This is a clever approach from Angular to defer the style parsing and thus minimize FOUC with CSS still being non-blocking. So yes, we do have a script violation taking place here.

The Angular team is well aware of it and they ship a IIFE to handle this. The IIFE changes the <link> tag attributes to activate the CSS rendering and unregister the onload event, once the CSS is activated.

Now the solution:

The Angular defined way to handle the CSP violation is to use a ngCspNOnce at the root element. This automatically triggers the nonce wherever required to handle the CSP (including the IIFE script). The only problem was to renew the nonce at the runtime.

To handle this: I started with a dummy nonce at the build time in my code. Angular auto propagates the nonce to handle CSP violation. During runtime, while serving each request, I wrote a simple logic to find the dummy nonce in my index.html file and replace it with a new cryptic nonce. This keeps the browser happy as far as CSP is considered.

There is obviously a performance hit since the index.html file now can't be cached and has to be regenerated every time (ideally not regenerated from scratch, just a string replacement of nonce is required). However all the other .js , .css and other assets can still be cached. The effective performance is still at par.

Hope this helps some one.

P.S: You can totally avoid the trouble caused by the second point if you opt for inlineCritical:false in your build configuration. For a small size application, this should be totally fine.