CSP-Analyse

Parses a Content-Security-Policy header value, ranks its weaknesses by severity, resolves the fallback chain per resource type, and answers the question you usually reach a browser console for: would this URL load, or would it be blocked?

Input: the header value only, without the Content-Security-Policy: prefix. Directives are separated by semicolons. The same value works for a <meta http-equiv> tag, except that frame-ancestors, report-uri and sandbox are ignored there.

Findings are ordered high, medium, low, then informational. The ones worth acting on first:

• 'unsafe-inline' in script-src — any injected <script> runs. Replace it with a per-response nonce or a hash. If both a nonce and 'unsafe-inline' are present, modern browsers ignore the latter, so it is only a fallback for ancient ones.
• Wildcards and schemes — * or https: in the script sources allows scripts from anywhere, which usually makes the rest of the policy decorative.
• Missing object-src, base-uri, frame-ancestors, form-action — the four directives that are easy to forget and that plug real attacks: plugin content, base-tag injection, clickjacking and form hijacking.
• Duplicate directives — a browser keeps the first occurrence and silently drops the rest, so a second script-src does nothing.
• Misspelled directives — silently ignored, so a typo means no protection at all.

Effective directive per resource type resolves the fallback chain: a script element consults script-src-elem, then script-src, then default-src; a frame consults frame-src, then child-src, then default-src. Where nothing is set at all, the resource is unrestricted.

URL check: give the page URL (which defines 'self') and the resource URL, pick the resource type, and the tool reports which source expression matched. Host matching follows the spec: a source without a scheme never allows an http URL on an https page, a source without a port implies the scheme's default port, *.example.com matches subdomains but not the bare domain, and a path is matched as a prefix when it ends with a slash.

Nonces and hashes cannot be evaluated from a URL alone, so a URL that only a nonce would allow is reported as blocked with a note. Inline scripts are outside the scope of a URL check by definition.

The recommended shape for a new policy is nonce-based: script-src 'nonce-{random}' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. With 'strict-dynamic', host allowlists are ignored and trust propagates from the nonced script to anything it loads, which removes the whole class of allowlist bypasses through open redirects and JSONP endpoints on allowed CDNs.

Limitations: static analysis of one header. It does not fetch your page, cannot see whether nonces are actually unique per response, and does not evaluate sandbox, trusted-types or report payloads.