Content-Security-Policy Generator

A server-rendered site with no third parties

Everything is served from one origin and there is no inline script, because the templates put their JavaScript in files. This is the policy every project should be able to reach, and the one most projects are two refactors away from.

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self';
  img-src 'self' data:;
  font-src 'self';
  connect-src 'self';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests

data: is in img-src for inline SVG icons and favicons; drop it if you have none. Note that 'self' does not include subdomains -- static.example.com needs naming.

Analytics, a tag manager, Google Fonts and a CDN

The common marketing stack, and the reason most real policies contain host allowlists. Each vendor needs a directive for the script and often a second one for what the script then talks to, which is the part people miss: adding the script host to script-src and forgetting connect-src produces a tag that loads and then fails silently.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com https://www.googletagmanager.com;
  style-src 'self' https://cdn.example.com https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https://www.googletagmanager.com https://*.google-analytics.com;
  connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com;
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'self'

Google Fonts is two hosts on purpose: the stylesheet comes from fonts.googleapis.com and the font files from fonts.gstatic.com, so a policy with only the first one loads the CSS and then blocks every @font-face in it.

A checkout page with Stripe, on a nonce

A payment page is where a policy earns its keep, and it is also where inline script is hardest to avoid. The answer is a per-response nonce rather than 'unsafe-inline', plus 'strict-dynamic' so the vendor script may load the further scripts it needs without you allowlisting hosts you cannot enumerate.

Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-r4nd0mPerResponse' 'strict-dynamic' https: 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https://*.stripe.com;
  connect-src 'self' https://api.stripe.com https://maps.googleapis.com;
  frame-src https://js.stripe.com https://hooks.stripe.com;
  object-src 'none';
  base-uri 'none';
  form-action 'self';
  frame-ancestors 'none'

The https: and 'unsafe-inline' tokens in script-src look like mistakes and are not: a browser that understands nonces ignores 'unsafe-inline', and one that understands 'strict-dynamic' ignores the host allowlist. They are there so an old browser degrades to a weaker policy instead of a broken page. This is the pattern Google publishes as a strict CSP.

A nonce has to be generated per response

The nonce is not a secret and it is not a password -- it is a value an attacker cannot guess in advance. Generate it once per request, put it in the header and on every script tag you trust, and never cache the HTML and the header separately, because a cached page with a stale nonce is a blank page.

Sixteen random bytes is the usual recommendation. Anything derived from the request -- a timestamp, a session id, a hash of the URL -- is predictable and therefore not a nonce.

<?php
// One nonce per response, before any output.
$nonce = base64_encode(random_bytes(16));

header(
    "Content-Security-Policy: "
    . "default-src 'self'; "
    . "script-src 'nonce-{$nonce}' 'strict-dynamic' https: 'unsafe-inline'; "
    . "object-src 'none'; base-uri 'none'"
);
?>
<script nonce="<?= htmlspecialchars($nonce, ENT_QUOTES) ?>">
  // This block runs. One without the attribute does not.
</script>

On a proxy, generate it where the HTML is generated

nginx can mint a nonce with ngx_http_sub_module or a Lua block, but the value has to reach both the header and the markup, and only the application knows the markup. The workable split is: application sets the header and the attributes, server config handles the static-file case where there is no inline script at all.

If you must set the policy in nginx, set the static one there and let the application override it for HTML responses. Two CSP headers do not merge into the looser of the two -- the browser enforces both, and only what satisfies every policy is allowed, which is usually not what the second header intended.

# nginx: policy for static assets only.
location ~* \.(?:css|js|woff2|png|svg)$ {
    add_header Content-Security-Policy "default-src 'none'" always;
}

# HTML is left to the application, which owns the nonce.
location / {
    proxy_pass http://app;
}

Hashes, when the inline block never changes

A build-time inline script -- a theme switcher, a bit of critical CSS -- can be allowed by the SHA-256 of its exact contents instead of a nonce. The hash covers the text between the tags only: no attributes, no surrounding whitespace differences. Change one character and the block stops running, which is either the point or an outage, depending on whether the hash is generated by your build.

Inline event handlers (onclick and friends) are a separate case: hashing them needs 'unsafe-hashes', which loosens the policy meaningfully. Moving them to addEventListener is nearly always the better trade.

# The hash of the exact inline body, base64-encoded:
printf %s 'document.documentElement.dataset.theme="dark"' \
  | openssl dgst -sha256 -binary | openssl base64

# Then, in the policy:
script-src 'self' 'sha256-Xp7A1s2Kk9Qm0bZ8vN3rL6cJdF3wA1uEoIgTzKbSxPk='

Collect the reports, then read them

report-uri is deprecated in favour of the Reporting API, and browser support is split in a way that makes shipping both the sensible answer today: report-to plus a Reporting-Endpoints header for Chromium, report-uri for everything else.

Budget for noise. A large share of real-world reports come from browser extensions injecting script into your page, and they are indistinguishable from an attack in the report body except by the blocked URI scheme. Filter chrome-extension:, moz-extension: and safari-extension: before anyone looks at the numbers, or the first week of data will bury the two reports that mattered.

Reporting-Endpoints: csp="/csp-report"
Content-Security-Policy-Report-Only: default-src 'self'; report-to csp; report-uri /csp-report

# What lands on /csp-report (classic format):
{
  "csp-report": {
    "document-uri":       "https://example.com/checkout",
    "effective-directive": "script-src-elem",
    "blocked-uri":        "https://widget.vendor.com/embed.js",
    "disposition":        "report",
    "original-policy":    "default-src 'self'; report-uri /csp-report"
  }
}