CSP Header Policy Checker

A Content Security Policy (CSP) gives the browser rules for loading and executing content. When a page requests a script, stylesheet, image, frame, font, connection, worker, or form destination, the browser compares that action with the directives delivered for the document. An enforced policy blocks violations; a report-only policy records them without blocking.

CSP reduces the impact of some cross-site scripting, compromised dependency, framing, and content-injection paths. It is a defense-in-depth control rather than a cure for the underlying bug. Output encoding, input handling, dependency review, cookie protection, access control, and security testing remain necessary even when a strict policy is present.

Directive

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

Source expression

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

Fallback

The directive used when a more specific fetch rule is absent. Many resource types fall back to default-src, while controls such as frame-ancestors do not.

Disposition

Whether a policy is enforced or monitored in report-only mode.

A long policy is not necessarily a strong policy. Script sources such as 'unsafe-inline', 'unsafe-eval', broad schemes, and wildcards can preserve the paths most likely to matter during an injection. Nonce- or hash-based script authorization narrows trust to specific script elements, and 'strict-dynamic' can extend that trust to scripts loaded by an already authorized script.

• object-src 'none' closes legacy plugin and object embedding when it is not required.
• base-uri limits injected base elements that could redirect relative URLs.
• frame-ancestors controls which parent pages may embed the document.
• form-action limits where forms may submit.
• Violation reporting provides evidence for rollout, but reports need filtering and operational ownership.

Delivery changes what the same text can do. The HTTP Content-Security-Policy header is the preferred enforced form. Content-Security-Policy-Report-Only supports staged monitoring. A meta policy cannot provide report-only behavior and does not support reporting, frame-ancestors, or sandbox; it also cannot protect resources loaded before the meta element.

Policy review must end at the deployed response, not the configuration file. Content delivery networks, reverse proxies, route-specific application code, and error pages can all produce different headers. A text check finds weak directives and risky allowances, while representative browser tests and violation reports show whether the policy is complete enough to enforce.

How to Use This Tool:

Review one delivered policy and one intended rollout posture at a time.

1. Paste a CSP value, complete header line, response-header block, or meta element into CSP header value. Preserve semicolons because they separate directives.
2. Name the review with Policy label, then choose the Assessment profile that matches a strict app, transitional host allowlist, or inventory-only pass.
3. Set Header delivery to the real disposition. Read any parsing note when the pasted header name disagrees, multiple CSP lines are present, or a meta policy is detected.
4. Choose whether reporting is required and how inline styles and wildcard hosts should be judged. These settings change particular findings; they do not rewrite the policy.
5. Use Directive ledger to confirm parsed sources and fallbacks, then work through Remediation queue from Critical and High findings downward.
6. Test the repaired policy in report-only mode on representative routes before enforcement when compatibility is uncertain.

Interpreting Results:

The numeric score summarizes this checker’s finding weights under the selected profile. It is not a browser conformance score or proof that the site is protected. The directive and remediation rows carry the decision evidence because they identify the allowance, missing control, delivery issue, or reporting gap behind each deduction.

Duplicate directives and multiple policy lines deserve separate attention. The browser enforces multiple policies independently, while the checker exposes repeated directive text for triage. Consolidate policy ownership and inspect the actual response before comparing scores across releases.

Technical Details:

A policy is parsed as semicolon-separated directives, each containing a lower-cased name and zero or more source tokens. For duplicate names, the first source list supplies fallback analysis and the duplicate count becomes a finding. Missing fetch directives follow defined chains such as script-src to default-src, or worker-src to child-src, then script-src, then default-src.

Formula Core:

The score starts at 100, subtracts every finding penalty, and is clamped to the 0 to 100 range.

S is the displayed score and each p is one penalty. Critical, High, Medium, and Low findings subtract 30, 18, 9, and 4 points. One High, one Medium, and two Low findings produce 65, which is Migration risk.

Rule Core:

'none' must appear alone to be meaningful; mixing it with other sources creates a finding. Unknown directive names are retained and marked Low so a typo or newer directive can be checked against current specifications instead of silently discarded.

The maximum input is 100,000 characters. Text extraction can read header lines and a simple quoted meta element, but it is not a browser parser or a full response evaluator. Multiple header lines, quoted delimiters, templated values, and dynamically assembled policies still require inspection at the delivered response.

Limitations and Privacy Notes:

The policy is analyzed in the browser. No site is fetched, no violation endpoint is contacted, and no route is crawled. The result cannot prove that all responses carry the same policy, that allowed hosts are trustworthy, or that representative pages work under enforcement.

• Remove private hostnames, reporting destinations, and environment labels before sharing copied or exported evidence.
• Capture the final public response after content delivery network and reverse-proxy changes.
• Use report-only evidence and browser tests to find necessary resources before removing compatibility allowances.

References:

• Content Security Policy Level 3, World Wide Web Consortium, 5 May 2026.
• Content Security Policy guide, MDN Web Docs.
• Content Security Policy Cheat Sheet, OWASP Cheat Sheet Series.
• How to audit HTTP security headers, Simplified Guide.