Content-Security-Policy header

CSP tells browsers which sources are allowed for scripts, styles, frames, fonts, and other resources. Defense against XSS and clickjacking. Misconfigured = legit resources blocked OR XSS still possible.

advanced W3C CSP3, RFC 7762 (header)

What the RFC says

A server may set a Content-Security-Policy header field to a CSP, which is a list of policy directives that define the security policy for a particular protected resource. (CSP3 §3.1) — W3C CSP3, RFC 7762 (header)

Example

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com 'nonce-{random}';
  style-src 'self' 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';
  upgrade-insecure-requests;

Real-world implementations

GitHub uses `Content-Security-Policy: default-src 'none'; ...` (deny by default, allowlist explicit).
Google: `script-src 'self' 'unsafe-inline' 'unsafe-eval' ...` (looser due to inline scripts).
Most modern apps: `script-src 'self' 'nonce-{cryptographically-random}'` for inline + bundled scripts.

Common misuses (don't do this)

Including `'unsafe-inline'` and `'unsafe-eval'` 'just to make it work' — defeats most XSS protection.
Forgetting `frame-ancestors 'none'` — leaves clickjacking possible (X-Frame-Options is deprecated for new sites).
Using `Content-Security-Policy-Report-Only` permanently — it never enforces. Roll out, monitor, then switch to enforcing.

Use cases

XSS mitigation
Third-party script audit
PCI-DSS / SOC2 compliance
Trusted Types adoption

Get the RFC reference for any HTTP response

httpwut takes a curl response and explains the status code + headers + the RFC sections you should actually read. Built for HTTP debugging that goes deeper than 'lol 500'.

Open httpwut