DNS Tools
CONTENT SECURITY POLICY

CSP Checker

Read the Content-Security-Policy a site sends, see each directive and source, and learn which parts weaken script protection.

Run Content Security Policy

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What a Content Security Policy is

Content-Security-Policy is a response header that tells the browser which sources a page may load scripts, styles, images, frames and connections from, and who may embed the page. Its main job is limiting the damage of cross-site scripting: even if an attacker injects markup, the browser refuses to run script from a source the policy does not allow. It is a second layer behind careful output encoding, not a substitute for it.

This tool reads the header on the landing response, splits it into directives, and reports which are present, which risky patterns appear, and which useful directives are missing. It also notes recognised good practice such as nonces, hashes, strict-dynamic and upgrade-insecure-requests, so a strict policy is credited rather than only criticised.

Enforced versus report-only

Browsers recognise two headers. Content-Security-Policy is enforced: violations are blocked. Content-Security-Policy-Report-Only is observational: violations are reported to an endpoint but nothing is blocked. The tool keeps them separate. A site with only a report-only policy is shown as having no enforced policy, though it is flagged as being in a testing stage. A site with both is typically trying out a stricter policy next to its current one. Report-only is the standard way to roll out CSP without breaking pages.

How to read the directive table

Each directive appears with its sources. The verdict follows one rule shared with the full assessment, and hardening notes are shown separately and not scored.

  • script-src (or default-src as fallback): the key directive. 'unsafe-inline' without a nonce, hash or 'strict-dynamic' makes it weak.
  • 'unsafe-eval': allows string-to-code execution.
  • Wildcard or broad sources: * or any https: source lets many origins supply script; any http: source allows unencrypted loading.
  • data: in script or object sources: can carry executable content.
  • Missing object-src, base-uri, frame-ancestors: noted as hardening gaps. frame-ancestors controls who can embed the page.
  • Credit: nonces, hashes, strict-dynamic and upgrade-insecure-requests are recognised as positive signs.

Common problems

  • Policy exists but allows unsafe-inline for scripts, which nullifies most XSS protection.
  • Only report-only is deployed and never promoted after testing.
  • Very broad allow-lists that include whole CDNs hosting user-supplied script.
  • Repeated directives: only the first counts, so an accidental duplicate is ignored.
  • Two layers each adding a header, producing a combined policy more restrictive than intended.

How to deploy or tighten CSP safely

Prerequisites: an inventory of the scripts, styles, frames and endpoints your pages use, and a way to receive violation reports. Risk: an enforced policy can break features that load resources from sources you did not list. Rollback: keep the previous header value and be able to remove the enforced header quickly while keeping report-only.

  1. Deploy a policy as Content-Security-Policy-Report-Only first and collect reports for a representative period.
  2. Remove inline script dependence where possible, or add per-response nonces or hashes.
  3. Start from a restrictive base such as default-src 'self' with object-src 'none' and base-uri 'self', then add only the sources you need.
  4. Move to the enforced header once reports are quiet, ideally keeping a report-only copy of the next stricter policy.
  5. Re-run this tool and test the key user journeys in real browsers.

Limits

The tool judges the structure of the header, not whether it breaks or protects a particular application; that cannot be known from one response. A policy delivered only through a meta tag is not seen. Only the landing page's headers are read, and different pages can send different policies. A policy is one layer; it does not replace input validation, patching or other headers.

Frequently asked questions

Will a strong CSP make my site secure?

It reduces the impact of script injection. It is one layer and does not replace secure coding or other controls.

What does report-only do?

It tells the browser to report violations without blocking them, so you can test a policy safely.

Why is unsafe-inline flagged?

It allows any inline script to run, which is exactly what injected code uses. Nonces or hashes are the safer approach.

My site has no CSP. Is that an error?

It is an improvement opportunity. Many sites run without one, but it is a useful defence against injected script.

Do I need frame-ancestors in CSP?

It is the modern way to control embedding. X-Frame-Options provides an older equivalent.

Does the checker test whether my policy breaks pages?

No. It reads the header from one response and judges its structure. Whether a policy blocks something your pages need is only visible in real browsers, through the console and violation reports.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09