CSP Header Policy Checker

Introduction:

A Content Security Policy, usually shortened to CSP, is a browser-enforced rule set for deciding which scripts, styles, images, frames, form targets, connections, fonts, media, workers, and related resources a page may use. The policy travels with the page as an HTTP response header in most production deployments. When the browser later sees a script tag, an inline handler, a stylesheet, a frame, or a network request, it compares that action with the policy before allowing it.

The main value of CSP is damage reduction. Cross-site scripting bugs, compromised third-party scripts, old plugin paths, and accidental embedding can still exist in the application, but a narrow policy can stop some injected code from running or stop a page from loading unexpected resources. That makes CSP a useful second control beside input handling, output encoding, dependency review, cookie settings, and normal security testing.

Policy text is easy to overread because a long header can still be weak. A broad host allowlist, https:, *, 'unsafe-inline', or 'unsafe-eval' may leave the highest-risk script paths open. A shorter policy built around nonces, hashes, 'strict-dynamic', object-src 'none', base-uri, and frame-ancestors can be stricter than a large inventory of allowed hosts.

Directive

A named rule such as script-src, object-src, base-uri, or frame-ancestors.

Source expression

A value inside a directive, such as 'self', a nonce, a hash, a scheme, a host, or 'none'.

Disposition

Whether the browser blocks violations or only reports them for migration evidence.

Fallback

The rule that applies when a more specific directive is missing, often through default-src.

Delivery mode changes the meaning of the same directive list. An enforced Content-Security-Policy response header blocks violations. A Content-Security-Policy-Report-Only response header collects evidence without blocking. A meta-delivered policy can help on static pages, but it cannot replace the full HTTP-header feature set for reporting, embedding control, sandboxing, and early resource coverage.

Good CSP review separates policy text from deployment proof. The text can reveal risky keywords, missing baseline directives, duplicate entries, and weak rollout choices. It cannot prove that every HTML response sends the same header, that violation reports are clean, or that a page will keep working after broad compatibility allowances are removed.

How to Use This Tool:

Check one policy at a time. A copied response-header block is better than a partial directive list because the header name, report-only state, duplicates, and line breaks can affect the review.

1. Enter a Policy label that names the host, route group, release, or environment being reviewed. Keep private hostnames out of the label if exported evidence will be shared.
2. Choose an Assessment profile. Use Strict app CSP for nonce or hash based hardening, Transitional allowlist CSP for migration cleanup, and Inventory-only review when you need a lower-pressure directive catalog.
3. Set Header delivery to the real delivery posture: enforced header, report-only header, both, or meta policy. If the pasted header name disagrees with the selection, resolve the parsing note before relying on the grade.
4. Paste the header value, full header line, response-header block, or meta tag into CSP header value. TXT, CONF, and saved header files can be dropped or browsed when the policy comes from server output or configuration.
5. Open Advanced when review policy matters. Keep reporting required for production or pilot rollouts, choose the inline style posture, and decide whether wildcard hosts should be treated as high-risk source expansion.
6. Read Policy parsing notes before the score. Empty values, mismatched delivery names, repeated CSP lines, duplicate directives, and directives with no source values can make the first result unsuitable for release notes.
7. Use Directive Ledger to confirm parsed directives, source lists, fallback status, and directive-level assessment. Then use Remediation Queue to work from the highest-severity findings down.
8. Open CSP Risk Profile for a severity count and use JSON only after the human-readable rows explain the same risk picture.

For migration work, start with report-only evidence, fix critical and high findings, keep reporting enabled, test representative pages, then promote the narrowed policy as an enforced HTTP response header.

Interpreting Results:

The grade is a text-level triage result, not proof of secure deployment. The score combines findings under the selected assessment profile. The remediation rows are the authoritative explanation because they name the directive, evidence, and recommended fix behind each penalty.

Critical findings usually mean script execution or delivery posture is too open for a strict policy. High findings cover missing baseline directives, permissive object embedding, broad script or connection sources, unsafe dynamic evaluation, or limited delivery. Medium findings often point to rollout cleanup such as report-only mode, missing reporting, broad form targets, duplicate directives, or mixed 'none' values. Low findings are still useful when the policy will become a template for other hosts.

Duplicate directives need cleanup before score comparisons. Browsers do not treat repeated directives as a neat merged source list, and multiple policies can make the effective behavior stricter than either policy appears by itself. Consolidate ownership between the application, server, and edge rule before using the score in a release checklist.

Treat broad compatibility allowances as temporary unless the application has a documented reason to keep them. 'unsafe-inline', 'unsafe-eval', scheme-only sources, data:, and wildcards are common reasons a policy looks present while still allowing paths that CSP is meant to restrict.

Technical Details:

A CSP value is a semicolon-separated policy. Each directive starts with a name followed by zero or more values. Fetch directives such as script-src, img-src, connect-src, worker-src, and font-src control where resources may load from. Document and navigation directives such as base-uri, frame-ancestors, and form-action control browser decisions that are not fully covered by fetch fallback rules.

default-src supplies fallback values for many fetch directives, but it is not a complete policy by itself. Script execution is reviewed more strictly because inline script, event handlers, javascript: URLs, eval-style APIs, broad source expressions, and third-party loaders can all affect cross-site scripting impact. Nonce or hash based authorization narrows trust to particular script elements, and 'strict-dynamic' lets trusted scripts load follow-on scripts without maintaining a large host list.

Rule Core

The review combines baseline coverage, script control, source breadth, delivery posture, and reporting. The selected profile changes severity for migration and inventory cases, while strict wildcard and inline-style choices adjust specific source findings.

Score Formula

The score starts at 100, subtracts each finding penalty, then clamps the result to the 0 to 100 display range.

S is the displayed score, p is one finding penalty, and n is the number of findings. Critical, high, medium, and low findings subtract 30, 18, 9, and 4 points. One high finding, one medium finding, and two low findings produce 100 - (18 + 9 + 4 + 4) = 65, which falls in the Migration risk range.

When more than one enforced policy is delivered, the protected resource must satisfy all of them. Additional enforced policies can only further restrict behavior. Report-only policies use the same parsing model for monitoring, but they do not block the resource. That distinction is why a copied response with multiple CSP lines should be treated as deployment evidence, not merely as a longer string.

Limitations and Privacy:

The checker evaluates the pasted policy text and selected review posture in the browser session. It does not fetch the reviewed site, crawl pages, inspect server routing, collect violation reports, or prove that every HTML response sends the same policy.

Avoid pasting secrets or sensitive internal labels into a CSP review. Policies can contain private hostnames, report endpoints, route names, and environment clues. Remove those details before sharing exported rows, copied JSON, or page URLs outside the team that owns the policy.

Worked Examples:

Nonce-based app policy

A production policy uses default-src 'self'; script-src 'nonce-r4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; form-action 'self'; report-to csp-endpoint. Under the strict profile with reporting required, the policy can reach Hardened territory if no broad sources or missing baseline directives remain. The release checklist still needs browser testing and violation-report review.

Legacy report-only migration

A migration header says Content-Security-Policy-Report-Only: default-src https:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; object-src 'self'; report-uri [reporting endpoint]. The review flags report-only delivery, active inline script, eval-style execution, broad sources, and object-src not being locked down. The result is useful for migration repair, but it should not be described as active hardening.

Duplicate edge and app directives

A response contains two script-src directives because the app sets one policy and an edge rule appends another. The directive ledger keeps both entries visible and the remediation queue asks for consolidation. Fix policy ownership first, then compare scores across releases.

Broken copied header

A copied value contains only Content-Security-Policy: or a directive name with no values. Parsing notes call out the missing policy tokens, and the directive count is too low to describe a real deployment. Recopy the exact response header, preserve semicolons between directives, and rerun the assessment before sharing the result.

FAQ:

References:

• Content Security Policy Level 3, W3C.
• Content Security Policy (CSP), MDN Web Docs.
• Content-Security-Policy header, MDN Web Docs.
• Content-Security-Policy: script-src directive, MDN Web Docs.
• Content Security Policy Cheat Sheet, OWASP Cheat Sheet Series.