flashman
← All guides

Content Security Policy deployment with nonces and hashes

Deploy Content Security Policy safely with directive fallbacks, per-response nonces or hashes, report collection, third-party inventories, and rollout tests.

2026-09-07 · 8 min read

  • csp
  • security
  • web

Content Security Policy constrains where a document may load or execute resources and can reduce the impact of cross-site scripting. It is delivered as an HTTP response header, with a report-only variant available for observation before enforcement.

A useful policy reflects the application's actual resource graph. Copying a broad allowlist or adding unsafe-inline until console warnings disappear creates complexity without establishing a meaningful execution boundary.

Inventory resource and execution paths

Map scripts, styles, images, fonts, connections, frames, workers, forms, navigation targets, and dynamically created resources. Include error pages, authentication redirects, analytics, ads, support widgets, and framework development behavior separately from production.

  • Start default-src from a restrictive baseline.
  • Add purpose-specific directives only for observed requirements.
  • Understand fallback rules before omitting a directive.
  • Remove sources when their owning integration is retired.

Choose nonce or hash authorization deliberately

For server-rendered dynamic pages, generate a cryptographically unpredictable nonce for every response and attach it only to approved script or style elements. Keep cached HTML and its policy header together so a stale nonce cannot be paired with new markup.

For stable inline content, a CSP hash can authorize the exact bytes. Recalculate it when whitespace or content changes, and verify which inline element type and browser behavior the directive covers.

Roll out with useful reports

Begin a significant policy change in report-only mode, collect reports at a bounded endpoint, and group them by effective directive, blocked URL, document, browser, and release. Reports are attacker-controlled telemetry and may contain sensitive URLs, so sanitize, rate-limit, and retain them narrowly.

  • Separate extension noise from application violations.
  • Test multiple simultaneous policy headers because they intersect.
  • Keep report-only and enforcing policy differences reviewable.
  • Alert on new high-volume violations after deployment.

Build repeatable policy fixtures

Use Flashman's hash and Base64 tools for public inline fixtures, URL tool for source expressions and redirects, diff for policy revisions, and HTML entities tool to inspect template escaping. Never treat a browser hash calculation as authorization for unreviewed code.

Test valid and stale nonces, exact and changed hashes, dynamic imports, workers, redirects, third-party failures, cached pages, error documents, report collection, supported browsers, and production minification.

Try these tools