--- title: "Introducing the Dynamic Content Security Policy (CSP) Integration" description: "Protect against common web exploits like cross-site scripting (XSS) attacks with this CSP integration. Avoid maintaining a static allowlist of domains!" source: "https://www.netlify.com/blog/general-availability-content-security-policy-csp-nonce-integration/" last_updated: "2026-07-14T01:14:30.000Z" --- > 💡 This blog post shows a dynamic approach of applying a Content Security Policy for the `script-src` directive. Other directives like `connect-src` would not benefit from this dynamic approach. ## The importance of a Content Security Policy The web is open by default: any website can fetch scripts, stylesheets, images, fonts, and more as a resource from any domain. However, that leaves the door open for malicious actors to execute scripts on your site and attack your visitors. **Website owners who value security of their websites, as well as their customers who use them, are encouraged to increase the security posture of the frontend of their website(s) by implementing a Content Security Policy.** ### What is a Content Security Policy (CSP)? A _Content Security Policy_ (CSP) is [“a mechanism by which web developers can control the resources which a particular page can fetch or execute”](https://www.w3.org/TR/CSP3/). It instructs the browser to **restrict network requests to a set of trusted domains** specified by the website. It is an effective tool in the security tool belt that helps prevent resources — scripts, stylesheets, images, etc — from loading or executing without the website owner’s consent. ![](https://cdn.sanity.io/images/o0o2tn5x/production/3ffb8c676dde02bf1cc35a880cddd6c34136b758-1600x809.png?auto=format) When we refer to a CSP, we are talking about a website’s `Content-Security-Policy` response header. The header’s value is a string of text, a semicolon-separated list of **directives** (like `script-src`, `image-src`, `connect-src`, etc) and their _source lists_, a list of domains (or content hashes) separated by spaces. This response header controls which external resources are allowed to be accessed by the site. **A CSP should be considered by any organization** concerned about client-side attacks, compliance, exfiltration of customer data, and website defacement. Sorry, your browser doesn't support embedded videos. ## Setting up a CSP is difficult to get right The problem with CSP is that it is notoriously fragile as well as tedious to maintain. Here are some common pitfalls you may encounter when specifying an allowlist of domains or content hashes that your website’s frontend is allowed to talk to: - **The CSP may block legitimate resources from loading or executing.** If you forget to include a domain on this list, and your code legitimately attempts to fetch from this domain, then that request will be blocked. - **Inline snippets will need their content hashes recomputed if they change.** If you employ the `script-src` directive without `'unsafe-inline'`, then [inline scripts won’t execute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_inline_script) unless you also include a SHA of its content in the CSP as well. You’ll need to either manually hardcode this hash (and adjust as needed whenever the script changes) or write a build step that computes and injects this hash for you. - **Traditionally, CSP response headers are static, not dynamic, when served from a CDN.** This means you’d need to maintain an allowlist of every single domain referenced by your site, which can easily balloon up to tens or hundreds of domains. But don’t worry - we have a better solution. Skip down to [_Simplifying CSP with dynamically-generated nonces_](#simplifying-csp-with-dynamically-generated-nonces) for a spoiler on how we can implement a dynamic nonce. In an effort to ease the operational risk of making CSP changes, a common strategy is to first deploy a `Content-Security-Policy-Report-Only` (CSP-RO) response header. This essentially sets up a dry-run of the CSP, reporting any _violations_ (resources that the browser would block due to the domain not being on the allowlist) to the URI specified in the CSP’s `report-uri` directive. With a CSP-RO in place, you can test your CSP candidate against real production traffic. However, this strategy isn’t foolproof: - **Only domains that users access during this test period will be reported.** Dusty corners of your app or site won’t be reported unless traffic is sent to them. Resources may point to different top-level domains (TLDs) based on the region the traffic is coming from (for example, `.de` domains may be accessed from Germany, whereas traffic from France might reach out to `.fr` domains), so if not all regions are active, then there will likely be holes in the reporting. - **The test period is ongoing and it does not end.** Typically, a CSP-RO is deployed alongside a CSP — acting kind of like a beta — where developers can test changes against production traffic to see if any violations are reported. If no violations are reported after some time, then the new rules are promoted to the CSP. The ongoing nature of CSP-RO is exhausting from a maintenance perspective. Consider a marketing team that owns the Segment or Google Tag Manager implementation of a site. They want to add a script so that data starts flowing to this new destination. Unless this new destination’s domain is already included in the CSP, **it won’t start working until developers make a code change to add it**. This creates a bottleneck of marketers waiting on developers, as the code change will require human approval in a pull request. As you can imagine, this allowlist would grow to become rather long. Take adding Google Analytics to the `connect-src` directive, for example: [Google itself recommends](https://developers.google.com/tag-platform/tag-manager/csp#google_analytics_4_google_analytics) that “each Google top-level domain (TLD) must be specified individually, since CSP syntax does not allow the use of wildcards on the right side of the hostname.” This number of [Google domains](https://www.google.com/supported_domains) is incredibly long (187 at time of writing!), and is what they recommend just to support a single service. Every external resource that the website reaches out to must be captured and documented, otherwise they will not load — it is strict by design. As a result, developers tend to be afraid to remove domains from this list, **so it grows to be an append-only list of rules** (much like a global stylesheet!). On top of that, this long allowlist is **included in every response** when served as a static header, inflating total request size and egress. Many companies try to deploy a CSP, but never make it past the CSP-RO stage — including us! We had tried to enforce a CSP on the [Netlify platform](https://app.netlify.com), but it never graduated from `Report-Only`, because 1) **the workflow to approve new domains to the allowlist was too cumbersome**, and 2) **we weren’t confident that we were capturing all allowed domains in our proposed allowlist.** [![On-demand webinar](https://no-cache.hubspot.com/cta/default/7477936/interactive-131420463505.png)](https://cta-service-cms2.hubspot.com/web-interactives/public/v1/track/redirect?encryptedPayload=AVxigLJBnTBd56nhxv6VOlQSa4tTK%2FHduA5UfRXLIn8mbwDNr6DHJkVyVE2GD7nRGEP7HcNiznFEy8C%2BindnuOscVbeqsvj75gWH4RuOsX4UWlh1D%2BuPOWHAUlwZpZYFyZN8QdC3UB75TU06BKDyN9gKqeqG7ahrYhEKOEAuTMKVRcJH4k%2F2rrq3V1JehT65d0V0HLye2ZyM%2BWqz5M61RhEYAcFKbFVfS7V%2FxVW7eKPRprbwzsRzn90Pxm301p1cONHYjipNdQU%3D&webInteractiveContentId=131420463505&portalId=7477936) ## Subresource integrity solves a different problem You may have heard of [subresource integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) (SRI). Script tags include the `integrity` attribute, whose value must match the hashed value of the resource’s content, otherwise the browser will refuse to execute it. The hash for subresource integrity is static/deterministic; that is to say, the value does not change unless the content changes. **But implementing SRI is only helpful if you are hotloading scripts from a third-party.** You want to be sure that the content you are downloading — such as a versioned library — does not change (either maliciously or accidentally). You also must calculate the sha ahead of time, and hardcode that value into your HTML, for it to become effective. **What SRI does not do is prevent cross-site scripting attacks (XSS).** If you have user-generated content on your site, or collect user input from forms or query parameters, then your frontend developers must go through extra lengths to ensure that a maliciously-crafted input wouldn’t allow for scripts to be injected on the page. Modern frameworks like React have guardrails in place to prevent this, but there are some use cases (notably rendering markdown into HTML) where unsanitized markup can find a way to the client. ## Simplifying CSP with dynamically-generated nonces The crux of the difficulty behind implementing a CSP successfully is that manually maintaining an allowlist is tedious. What if instead of maintaining an allowlist, we could guarantee integrity dynamically? That’s exactly what a [CSP nonce](https://content-security-policy.com/nonce/) does: on every request, a randomly-generated cryptographically-secure string gets included in the CSP’s `script-src` directive. If the random string from the CSP header does not equal the value in a `