CSP Safe Rollout: Report-Only to Enforce in Six Stages

CSP in one paragraph

CSP is a browser-enforced allowlist for every resource your HTML can pull in. When a page tries to load something that is not explicitly allowed, the browser refuses and (optionally) posts a violation report to an endpoint you control. Done properly, CSP turns a critical XSS - an attacker injecting <script> into your HTML - into a noisy console error that doesn't execute. Done sloppily (unsafe-inline, wildcard hosts), CSP is a compliance prop with none of the security it advertises.

The six-stage rollout

Do not try to ship a strict CSP on day one. Real pages load more resources than anyone remembers, and a too-strict policy enforced on day one breaks the site. The working pattern is: learn what your site loads, formalise a policy, deploy as Report-Only, tighten, then flip to enforce.

Stage 1 - Baseline inventory

Ship a Content-Security-Policy-Report-Only header with a deliberately permissive policy and a reporting endpoint. The goal is to discover what your pages actually load, including the long tail of marketing scripts, feature flags, and preview-only analytics.

Content-Security-Policy-Report-Only:
  default-src *;
  script-src * 'unsafe-inline' 'unsafe-eval';
  style-src * 'unsafe-inline';
  report-to csp-endpoint;

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://csp-reports.example.com/report"}]}

This is deliberately open - the point is to learn. Run it for at least two weeks. Collect violation reports. Tag each violated source: 'ours' (we own it), 'vendor' (approved third party), 'unknown' (investigate).

Stage 2 - Shape the real policy

From the reports, draft the real policy. Categorise every host into the directive it belongs in: script-src, style-src, img-src, font-src, connect-src, frame-src, media-src. Enumerate hosts explicitly - avoid wildcards if you can.

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'unsafe-inline' https://cdn.example.com https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  report-to csp-endpoint;

Stage 3 - Introduce nonces

Generate a fresh random nonce on every HTML response (server-side). Emit it both in the CSP header and on every inline <script> you legitimately ship.

import crypto from 'node:crypto';

app.use((req, res, next) => {
  const nonce = crypto.randomBytes(16).toString('base64');
  res.locals.nonce = nonce;
  res.setHeader(
    'Content-Security-Policy-Report-Only',
    `default-src 'self';
      script-src 'self' 'nonce-${nonce}' 'strict-dynamic' https:;
      style-src 'self' 'unsafe-inline';
      object-src 'none';
      base-uri 'self';
      frame-ancestors 'none';
      report-to csp-endpoint;`.replace(/\s+/g, ' ').trim()
  );
  next();
});

<!-- every inline <script> the server emits gets the nonce -->
<script nonce="<%= nonce %>">
  window.__CONFIG__ = { featureX: true };
</script>

strict-dynamic is the magic word: it tells the browser to trust scripts that an already-trusted (nonced or hashed) script loads. That means host allowlists become irrelevant for script-src - which is exactly what you want, because host allowlists are trivially bypassable.

Stage 4 - Hash the inlines you cannot nonce

Some inline snippets (third-party widgets, static analytics tags) cannot accept a dynamic nonce. For those, compute a SHA-256 of the exact script body and whitelist the hash.

echo -n "console.log('hello');" | openssl dgst -sha256 -binary | openssl base64
# → e.g. IiwQvCiDCWFZ0ypaHFj4W2bJ5b3pz0p6X8v1Yc2o3P0=

script-src 'self' 'nonce-{{RANDOM}}' 'sha256-IiwQvCiDCWFZ0ypaHFj4W2bJ5b3pz0p6X8v1Yc2o3P0=' 'strict-dynamic';

Stage 5 - Remove 'unsafe-inline'

With every legitimate inline script either nonced or hashed, drop 'unsafe-inline' from script-src. Watch the violation reports for anything you missed. Fix or hash each one. Repeat for style-src once you have moved all inline styles to external stylesheets or to nonced <style> blocks.

Stage 6 - Enforce

Rename the header from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the same policy body. Keep reports on (you still want visibility). Watch error rates for 24 hours. If nothing breaks, you are done.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{{RANDOM}}' 'strict-dynamic';
  style-src 'self' 'nonce-{{RANDOM}}';
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://api.example.com;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  form-action 'self';
  report-to csp-endpoint;
  upgrade-insecure-requests;

Common pitfalls

• Host allowlists in script-src: *.cloudfront.net allows every attacker-uploaded CloudFront asset. Replace with nonces + strict-dynamic.
• Static nonces: the nonce must be regenerated per response. A build-time nonce is effectively no nonce at all.
• Caching nonced HTML: a CDN that caches the HTML caches the nonce too - so either bypass the cache on HTML or use hashes for inline scripts.
• Missing frame-ancestors: without it, X-Frame-Options (or nothing at all) is enforcing your clickjacking posture. frame-ancestors is the modern, strict replacement.
• object-src default: without object-src 'none' you leave <object> and <embed> open to Flash-era bypasses.
• Report endpoint cost: busy sites generate thousands of violation reports. Sample or throttle, or use a SaaS processor.