CSP Policy Brief
{{ scoreLabel }}
{{ summaryLine }}
{{ gradeLabel }} {{ actualDirectiveCount }} directives {{ criticalFindings.length }} critical {{ highFindings.length }} high
Use a short deployment label so exported evidence is easy to tie back to a release or host.
Choose how hard to grade script controls while keeping baseline directive checks active.
Select whether the pasted policy is enforced, report-only, both, or a meta tag fallback.
Paste one policy at a time; duplicate directives are retained in the evidence table and flagged.
{{ sourceStatusLine }}
Require a CSP reporting directive when reviewing production or pilot rollouts.
Use strict style posture for new apps; compatibility lowers style-src unsafe-inline from high to warning.
Treat wildcard hosts strictly
Flag broad host patterns such as * and https: as high-risk source expansion.
Directive Sources Fallback Assessment Copy
{{ row.directive }} {{ row.sourcesDisplay }} {{ row.fallback }} {{ row.assessment }}
No directives were parsed from the current input.
Priority Finding Evidence Recommended fix Copy
{{ row.severityLabel }} {{ row.title }} {{ row.evidence }} {{ row.fix }}
No remediation items for the current policy profile.
Tags: HTTP, Security
Export to PDF Fullscreen
Customize
Advanced
:

Content Security Policy, usually shortened to CSP, is a browser security policy that tells a page which scripts, styles, images, frames, connections, and other resources are allowed. A good policy narrows where executable code can come from and limits what injected markup can change. A weak policy can look present on a scanner while still leaving inline scripts, broad host allowlists, or missing baseline directives in place.

CSP review flow from header text through directive checks to severity findings
A CSP review starts with the delivered policy, checks directives and risky source tokens, then separates findings by severity before rollout decisions.

CSP review matters most when a policy is moving from observation to enforcement, when a legacy allowlist is being tightened, or when a release adds new script, frame, form, or API endpoints. A policy with Content-Security-Policy-Report-Only can collect evidence without blocking users. An enforced Content-Security-Policy header can block violations, so mistakes are more visible and more disruptive.

A checker can identify risky tokens and missing directives, but it cannot prove that a policy matches every route, template, browser, and third-party dependency in production. Treat a strong result as a review aid. Confirm changes with real report samples, browser testing, and staged rollout before relying on CSP as the only defense against cross-site scripting.

Technical Details:

A CSP value is a semicolon-separated set of directives. Each directive begins with a directive name such as script-src, default-src, or frame-ancestors, followed by source expressions or keywords. Fetch directives restrict where resource types may load from. Document and navigation directives cover actions such as base URL handling, form submission, embedding, and legacy plugin content.

The governing rule is not a single pass/fail test. A browser combines policy delivery, directive fallback, source-list semantics, and enforcement mode. default-src acts as a fallback for many fetch directives, but it does not replace every hardening directive. frame-ancestors and form-action need their own review because embedding and form submission risks are not solved by a narrow script policy.

Rule Core

The checker normalizes the pasted policy into directives, keeps duplicate entries visible, and then builds findings from baseline coverage, risky source tokens, delivery mode, and the selected review profile. It accepts a raw policy value, a full CSP header line, full response-header text, or a meta-delivered policy. If more than one CSP header line is pasted, the parser warns because multiple policies can interact in restrictive ways.

Review Area Checked Signal Why It Matters
Baseline directives default-src, script-src, object-src, base-uri, frame-ancestors, and form-action These cover broad resource fallback, script control, legacy object embedding, base tag injection, page embedding, and form submission targets.
Script risk 'unsafe-inline', 'unsafe-eval', missing nonces or hashes, missing 'strict-dynamic', and broad script sources Script execution is where CSP most directly reduces cross-site scripting impact. Broad script permissions can leave the page exposed even when a policy exists.
Source breadth *, scheme-only sources such as https:, data:, and wildcard hosts when strict wildcard review is enabled Broad sources expand what the browser can load and can hide accidental trust in unrelated hosts or data URLs.
Delivery and rollout Enforced header, report-only header, both modes, or meta delivery Report-only mode observes without blocking. Meta delivery is more limited than an HTTP response header and cannot cover every CSP feature.
Reporting report-to or report-uri, depending on the selected reporting requirement Reports help confirm what would break during migration and provide evidence before enforcement.

Score and Grade Logic

The score starts at 100 and subtracts weighted penalties for findings. Critical findings subtract 30 points, high findings subtract 18, medium findings subtract 9, and low findings subtract 4. The final value is clamped between 0 and 100, then converted into a grade label.

Grade Score Range Meaning in This Checker
Hardened 90 to 100 The selected profile found no serious gaps and only small or no remaining notes.
Reviewable 75 to 89 The policy may be close enough for staged review, but remaining findings should still be read before enforcement.
Migration risk 55 to 74 The policy has enough gaps that a rollout plan should include remediation and report review.
Weak 0 to 54 Critical or repeated high-impact findings make the policy unsuitable as a hardening control without changes.

The strict review profile expects nonce or hash based script authorization and treats missing strict script controls as high risk. The transitional profile is more tolerant of allowlist migration work. The inventory profile still flags major issues, but it is meant for cataloging an existing policy rather than judging enforcement readiness.

Everyday Use & Decision Guide:

Start with the header as it is actually delivered. Paste the full Content-Security-Policy or Content-Security-Policy-Report-Only line when you have it, not only the directive value copied from a ticket. The header name lets the checker warn when the selected delivery mode disagrees with the pasted source.

Use Strict app CSP for new application work or for a policy intended to block script injection. Use Transitional allowlist CSP when a legacy site still depends on host allowlists while inline code is being removed. Use Inventory-only review when the goal is to understand what a policy contains before deciding how hard to grade it.

  • For production rollout, leave Require report-to or report-uri enabled so missing reporting appears in the remediation queue.
  • For older frontends with framework-generated inline styles, switch Inline style posture to compatibility only if style cleanup is not part of the current release.
  • Keep Treat wildcard hosts strictly enabled when broad hosts such as *, *.example.com, or scheme-only sources need extra scrutiny.
  • Use the strict sample to compare a nonce-based policy shape. Use the legacy sample to see why 'unsafe-inline', 'unsafe-eval', and broad sources carry risk.

The most useful first read is the summary score plus the critical and high badges. Then open Remediation Queue before editing the policy. It groups actionable findings with evidence and a recommended fix, which is usually faster than scanning the raw directive ledger first.

Do not treat a clean-looking score as proof that the policy is ready for every route. CSP depends on real browser behavior, response path, and application code. After the checker shows no blocking findings, run the policy in report-only mode or a staged environment and compare report samples against the directives you plan to enforce.

Step-by-Step Guide:

  1. Enter a short Policy label such as admin.example.com production so copied rows, JSON, and exported evidence can be tied back to the reviewed host or release.
  2. Choose the Assessment profile. Start with Strict app CSP for a new policy, or use Transitional allowlist CSP when reviewing a legacy migration.
  3. Set Header delivery to match the real deployment. If the pasted header name conflicts with the selection, a parsing note warns you before you trust the result.
  4. Paste the CSP value, full header line, full response headers, or a meta tag into CSP header value. You can also browse for a TXT, CONF, or headers file under 1 MB, or drop copied header text onto the field.
  5. Open Advanced when you need to require reporting, relax inline style posture for compatibility, or tighten wildcard handling.
  6. Read Policy parsing notes first. Fix an empty policy, wrong delivery mode, multiple-header surprise, or malformed source value before treating the score as meaningful.
  7. Open Directive Ledger to confirm each parsed directive, source list, fallback status, and directive-level assessment.
  8. Open Remediation Queue and clear critical or high findings before moving the policy toward enforcement.
  9. Use CSP Risk Profile and JSON when you need a severity snapshot or a structured handoff record for a release review.

Interpreting Results:

The score is a triage signal, not a browser guarantee. A Hardened grade means the selected profile found no serious issues in the pasted policy text. It does not prove that every page route has the same header, that reports are quiet under live traffic, or that all target browsers behave identically.

Severity Typical Meaning Practical Follow-up
Critical Script execution is still broadly exposed, such as active 'unsafe-inline' without a nonce/hash plus 'strict-dynamic' pattern. Fix before enforcement review. Move inline handlers or authorize exact scripts with nonces or hashes.
High A baseline hardening directive is missing, script evaluation is allowed, meta delivery is limited, or a broad source expands trust too far. Resolve before treating the policy as production-ready.
Medium The policy has rollout or hygiene gaps such as duplicate directives, broad form actions, missing reporting, or 'none' mixed with other sources. Clean up during migration and confirm the intended browser behavior.
Low The checker found compatibility or hardening notes such as unknown directive tokens, absent 'strict-dynamic', report-uri without report-to, or missing HTTPS upgrade. Review after high-impact items are gone, especially before standardizing a policy template.

Read duplicate directives carefully. The directive ledger keeps duplicate entries visible because browsers do not treat two repeated directives as a neat merge of both source lists. Consolidating duplicates into one directive makes the policy easier to reason about and easier to compare between releases.

The JSON output is useful for handoff, but the remediation rows are the best place to decide what to change first. Fix critical script issues, broad source allowances, and missing baseline directives before spending time on lower-risk notes such as Trusted Types planning or optional HTTPS upgrade cleanup.

Worked Examples:

New app policy with nonce-based scripts

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. With Strict app CSP and reporting required, the summary can land in Hardened territory if no broad sources or missing baseline directives remain. The useful follow-up is browser and report testing, not adding extra host allowlists.

Legacy report-only policy that still allows too much script

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 https://reports.example.com/csp. The tool warns that the delivery is report-only, flags active inline script, eval-style execution, broad sources, and object-src not being locked down. The grade should be read as migration risk even though the policy is useful for collecting reports.

Meta-delivered policy with missing embedding protection

A page contains a meta CSP tag copied from a static template. The checker parses the content but adds a note that meta delivery has limited coverage. If frame-ancestors is missing, the remediation queue shows that embedding policy still needs attention. The practical fix is to move the policy to the HTTP response header and add explicit embedding rules there.

Troubleshooting an empty or malformed result

A pasted value contains only Content-Security-Policy: or a directive name with no sources where sources are expected. The large summary stays weak, the directive count is low or zero, and parsing notes point to missing source values. Recopy the exact response header, check semicolons between directives, and rerun before treating the result as a real policy review.

FAQ:

Can I paste full response headers?

Yes. The parser looks for Content-Security-Policy and Content-Security-Policy-Report-Only header lines inside pasted text. If it finds multiple CSP lines, it warns so you can review how the policies interact.

Why does report-only mode lower confidence?

Report-only mode records violations without blocking them. It is useful for rollout evidence, but users are not protected by that policy until the hardened version is delivered as an enforced header.

Why is 'unsafe-inline' severe for scripts but less severe for compatibility styles?

Inline script can reopen the main cross-site scripting risk CSP is meant to reduce. Inline styles can still be worth removing, but the tool lets you lower style severity when a legacy frontend still needs style compatibility during migration.

Does a high score mean my CSP is ready to enforce?

No. A high score means the pasted policy text matches the selected rule checks well. You still need route coverage, browser testing, report review, and a staged rollout plan before enforcement.

What should I do when the checker says a directive is duplicated?

Combine the intended sources into one directive and remove the duplicate. Repeated directives are hard to audit and may not behave like a merged list in the browser.

Is the pasted policy sent to a CSP scanning service?

No server-side CSP scan is used by this checker. The policy is parsed in the browser, but it can be reflected in page state and shared URLs, so avoid sharing links that contain sensitive internal hostnames or endpoint paths.

Glossary:

Content Security Policy
A browser policy that restricts resource loading, script execution, embedding, navigation, and related security-sensitive behavior.
Directive
A named CSP instruction such as script-src, default-src, base-uri, or frame-ancestors.
Source expression
A token or host pattern inside a directive that tells the browser where a resource may come from.
Nonce
A per-response value that can authorize specific script elements without allowing all inline scripts.
Hash
A digest that authorizes an exact inline script or style when the content matches the declared value.
Report-only
A CSP delivery mode that reports violations without blocking the behavior that triggered them.

Responsible Use Note:

Use this checker as part of a CSP rollout review, not as a replacement for security testing. A policy can pass static checks and still miss an application route, break a browser-specific path, or allow a trusted third-party script to load risky follow-on code. Keep report collection, manual review, and staged enforcement in the release process.

References: