Recommended CSP for static file hosting

Start with the CSP section at angular.dev/best-practices/security#content-security-policy, then review Angular CLI issues #32522, #33844, and #32405 plus Angular #54031. Document a static-hosting path, explain autoCsp and the cited build options and tradeoffs, and distinguish remaining runtime or application CSP requirements; done when the guidance covers unchanged, cached HTML without assuming edge rewriting.

Describe the problem that you experienced

Hosting a SPA as prebuilt static files is popular and has many advtanges - quicker to deploy, simpler to operate, and easier to serve globally through a CDN. It also removes the server runtime from the deployment, saving one more thing to get compromise or patch.

The CSP guidance’s minimal policy includes nonces in script-src and style-src, and says the server should generate a fresh nonce for each request. That works when a server or edge layer can generate a nonce and insert the matching value into both the CSP and the HTML. For static hosting that serves the built HTML unchanged, the documentation is silent on what to do.

The section mentions autoCsp, but doesn’t explain whether it’s a suitable option for static hosting, what policy it produces, or what limitations come with its use. It also warns that caching nonce-bearing HTML can cause a nonce to be reused, and recommends generating nonces at the edge. That leaves static-hosting users without a clear, practical path.

Enter the URL of the topic with the problem

https://angular.dev/best-practices/security#content-security-policy

Describe what you were looking for in the documentation

Guidance for configuring CSP when deploying an Angular SPA as prebuilt static files, such as files served from object storage, GitHub Pages, Azure Static Web Apps, Netlify, or Cloudflare Pages. In particular, guidance for hosts that cache and serve the same HTML to multiple users without rewriting it for each response.

Describe the actions that led you to experience the problem

1. Build a basic Angular application for production.
2. Serve its generated files unchanged from a static host and configure a CSP response header.
3. Disallow inline scripts and event handlers, for example with script-src 'self' (as per the recomended CSP minus the nonce).
4. Observe CSP violations from inline content in the generated HTML.

Describe what you want to experience that would fix the problem

It would be great if the documentation explained which CSP approach to use for static hosting (or with CDN caching).

It would also help to explain when Angular actually needs a nonce and whether autoCsp is intended to address this scenario.

For a basic CLI-built app, two build options appear to account for the relevant build-generated script and handler content:

• subresourceIntegrity adds an inline import map containing integrity metadata. Browsers apply inline-script CSP checks to the import map.
• optimization.styles.inlineCritical can produce a stylesheet onload handler to switch the stylesheet media. This is an event handler, governed by script-src-attr or its fallback; a nonce on a <script> element does not authorize it.

Turning off those options avoids these particular outputs:

{
  "build": {
    "options": {
      "subresourceIntegrity": false
    },
    "configurations": {
      "production": {
        "optimization": {
          "styles": {
            "inlineCritical": false
          }
        }
      }
    }
  }
}

For a basic app, these seem to be the two build-generated sources behind the script-side CSP violations, so documenting this option should be fairly straightforward. It would be useful to say whether disabling them removes the need for a script-src nonce for that build output, and to explain the tradeoffs: disabling SRI removes its integrity checks, and disabling critical CSS inlining may affect initial rendering performance.

The documentation should also make clear that this does not necessarily remove all CSP requirements. Angular runtime-inserted styles, application code, or third-party libraries may still need separate handling under style-src or other directives.

If this problem caused an exception or error, please paste it here

Executing inline script violates the Content Security Policy directive
"script-src 'self'". The action has been blocked.

Executing inline event handler violates the Content Security Policy directive
"script-src 'self'". The action has been blocked.

If the problem is browser-specific, please specify the device, OS, browser, and version

Any browser that supports CSP - hopefully all of them.

Provide any additional information here in as much as detail as you can

Related discussions cover parts of this topic:

• Angular CLI #32522 describes the inline onload handler associated with critical CSS inlining.
• Angular CLI #33844 discusses an interaction between autoCsp and SRI. It is related, but addresses a different behavior.
• Angular #54031 discusses CSP and runtime-inserted style attributes.
• Angular CLI #32405 is a broader discussion about CSP and SPAs, including build-time hash output.
• This Stack Overflow question illustrates users experimenting with a fixed nonce and recognizing that it is not good practice. Not everyone will read that far.

[^1]: Per-response nonce injection at a CDN or edge can be an option, but it requires provider-specific logic to keep the CSP and HTML in sync. Transforming HTML on delivery can also make caching the final response more complicated, so it would be helpful to describe this as an alternative rather than assume it is available to every static host.

[^2]: Broader improvements to Angular CSP support and automation are also discussed in Angular CLI #32405.

LLM disclosure: I used a LLM to help draft this issue. I read and revised it with my human eyes before submitting it.