Content-Security-Policy evaluator

How a browser reads a policy

The rules come from the W3C's Content Security Policy Level 3 specification. A policy is a list of directives separated by semicolons. Each directive is a name followed by a list of sources, separated by spaces. Three rules catch people out:

• The first occurrence of a directive wins. If script-src appears twice, the second one is ignored entirely. Policies assembled from several config files often end up like this.
• Keywords need single quotes. 'self' means "this origin"; self without quotes is read as a host called self and matches nothing.
• Fallback is per directive. script-src, img-src, connect-src and the other fetch directives fall back to default-src. frame-src first tries child-src; worker-src tries child-src, then script-src. base-uri, form-action and frame-ancestors do not fall back at all.

The second table in the result applies these rules, so you can see what each resource type is actually allowed, rather than what the policy appears to say.

What is checked, and why

Most of the checks concern scripts, because stopping injected script (cross-site scripting) is the main job of a CSP. The approach follows the research published by Google's security team (Weichselbaum and others, CSP Is Dead, Long Live CSP!, ACM CCS 2016), which found that most real-world policies based on host allowlists could be bypassed, and recommended nonces or hashes with 'strict-dynamic' instead.

A worked example

The weak example above is the kind of policy many sites ship first. It has a default-src 'self', which looks restrictive, but then:

• script-src 'self' 'unsafe-inline' … allows inline script with no nonce or hash, so an injected <script> block runs. This is the one serious failure.
• object-src is not set, so it inherits 'self' from default-src. Better than nothing, but 'none' is the recommendation.
• There is no base-uri and no form-action, and neither falls back to default-src.
• img-src * allows images from anywhere. That is common and not a script risk, so it is not flagged, but it does mean an injected image tag can send data to any server in its URL.

Press Strict example to compare a policy built the recommended way: a per-response nonce, 'strict-dynamic', object-src 'none' and base-uri 'none'. Its https: and 'unsafe-inline' are there only for very old browsers and are reported as ignored rather than as failures.

Moving from an allowlist to nonces

1. Generate a fresh random nonce (at least 128 bits, base64) for every response, in the server or framework, never a fixed value.
2. Add nonce="…" to every <script> tag the page itself writes, including the loader snippets for analytics or tag managers.
3. Move inline event handlers (onclick="…") into script files; nonces do not cover them.
4. Ship script-src 'nonce-…' 'strict-dynamic'; object-src 'none'; base-uri 'none' as Report-Only first, read the reports, then enforce it.

Limits of a static check

This evaluator reads text. It cannot know whether a host you allow serves a JSONP endpoint, whether your nonce is really random per response, or whether a script you trust with 'strict-dynamic' will load something unsafe. It evaluates the first policy only, where a header carries several separated by commas (browsers enforce all of them together). And it does not know which browsers your visitors use: directives such as require-trusted-types-for are enforced in Chromium-based browsers only.