CSP Header Builder

Constraining what a page can load

A Content-Security-Policy tells the browser which sources of scripts, styles, images, and other resources are allowed, and blocks everything else. Done well, it is the strongest single defense against cross-site scripting, because even if an attacker injects a script tag, the browser refuses to run code from a source your policy did not approve.

Directives, source lists, and nonces

A policy is a set of directives like script-src, style-src, and default-src (the fallback), each with a source list. Sources can be origins, the keyword self, a nonce- value tying a specific inline script to the policy, or a hash of the script's contents. Nonces and hashes are how you keep necessary inline scripts without opening the door to injected ones.

Example

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data:;
  frame-ancestors 'none'

Here scripts run only from the same origin or when they carry the matching nonce, and frame-ancestors 'none' blocks the page from being framed, covering what X-Frame-Options used to.

The unsafe-inline problem

Adding 'unsafe-inline' to script-src is the quickest way to make a strict CSP work, and it also guts the protection, since injected inline scripts are exactly what CSP exists to stop. Roll out with Content-Security-Policy-Report-Only first so violations are reported but not enforced, then tighten. Verify the final header lands with the header analyzer.

FAQ

My styles broke after adding a CSP, why? A strict policy blocks inline style attributes and tags. Move styles to files, or allow them with a nonce or hash rather than reaching for unsafe-inline.

Should I use default-src as a catch-all? Yes, set a restrictive default-src and then loosen specific directives only as needed, rather than listing every directive from scratch.