How to Configure a Strict Content Security Policy (CSP) Without Breaking Your Site

Content Security Policy (CSP) is one of the most powerful browser security mechanisms ever standardized, yet many development teams avoid it due to fears of breaking user interfaces. A poorly configured policy can disable essential third-party analytics, fonts, and payment gateways.

Deploying a modern “strict” CSP using cryptographic nonces provides robust Cross-Site Scripting (XSS) immunity without requiring endless domain allowlists.

The Flaw in Traditional Domain Allowlisting

In earlier CSP specifications, developers maintained extensive lists of approved domains:

Content-Security-Policy: script-src 'self' https://cdnjs.cloudflare.com https://apis.google.com;

Security researchers proved that domain allowlists are inherently fragile:

• If an allowed CDN hosts an outdated JSONP endpoint or vulnerable Angular library, an attacker can bypass the CSP completely.
• Every time marketing adopts a new software vendor, the engineering team must update server header policies.

The Modern Nonce-Based Approach

Google and OWASP recommend a Strict CSP architecture:

Content-Security-Policy:
  object-src 'none';
  script-src 'nonce-{RANDOM_BASE64}' 'strict-dynamic' https: 'unsafe-inline';
  base-uri 'none';

How it works:

1. On every HTTP response, your web server generates a cryptographically random 128-bit string (e.g., nonce-4B9Xk2Lp0zQ...).
2. That token is placed in the HTTP header and attached to valid inline script tags: <script nonce="4B9Xk2Lp0zQ...">.
3. The browser only executes scripts matching that specific one-time token.
4. Any malicious script injected via stored or reflected XSS lacks the nonce and is blocked immediately.