Skip to main content
SiteIndex
DeveloperReady to use

CSP Header Parser

Break a Content-Security-Policy header into its individual directives and sources for review.

Guide

Interactive workspace

No account required
CSP Header Parser

Paste a policy value, a full response-header block (the Content-Security-Policy line is extracted automatically), or fetch a live URL below.

Security score
60/100 · Grade C
0 critical · 1 warnings · 6 missing baseline directives
Starts at 100: −25 per critical, −10 per warning, −5 per missing directive.
DirectiveSourcesFinding
default-src
'self'
OK
script-src
'self'https://cdn.example.com
OK
img-src
*
Warning
object-src
'none'
OK

Findings and fixes

  • Warningimg-src

    Wildcard * in img-src allows content from any origin on the internet.

    Fix: Replace * in img-src with the specific origins you actually load from, for example https://cdn.example.com.

Missing baseline directives

style-srcconnect-srcfont-srcbase-uriform-actionframe-ancestors

Fetch directives not listed fall back to default-src when one is set; base-uri, form-action, and frame-ancestors have no fallback and should be set explicitly (for example object-src 'none'; base-uri 'self'; frame-ancestors 'none').

How to read a CSP

A Content-Security-Policy is a list of directives separated by semicolons. Each directive names a kind of content (script-src for JavaScript, img-src for images, and so on) followed by the sources it may load from: 'self' means your own origin, a host like https://cdn.example.com allows that host, and 'none' blocks the type entirely. When a directive is missing, browsers fall back to default-src for most fetch types — but not for base-uri, form-action, or frame-ancestors.

'unsafe-inline' and 'unsafe-eval' switch the protection off for the most common attack paths; nonces ('nonce-…') and hashes ('sha256-…') are the safe way to allow specific inline blocks. A sensible minimum policy is: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self' — then add the hosts you need per directive. To trial a policy without breaking the site, send it as Content-Security-Policy-Report-Only first and watch the reports.

Where do I copy a CSP from?

In your browser's developer tools, open the Network tab, reload, click the main document request, and look under Response Headers — or paste any URL into the fetch box above and the header is loaded for you.

Does a good grade here mean my site is secure?

No. The grade reviews this one header against common weaknesses. It does not test your application code, other headers, or your server configuration, and a strict policy that is wrong for your site can still break pages — deploy changes in report-only mode first.

Why is 'unsafe-inline' scored as critical?

Most CSP deployments exist to stop cross-site scripting. 'unsafe-inline' in script-src lets any injected inline script run, which cancels that protection; security-header scanners and Google's CSP Evaluator treat it the same way.

What is the difference between CSP and CSP Report-Only?

Content-Security-Policy is enforced — violations are blocked. Content-Security-Policy-Report-Only only reports violations to the endpoint you name, so you can find breakage before enforcing.

My framework adds inline scripts. How do I keep them?

Have the framework emit a per-request nonce and add 'nonce-VALUE' to script-src, or precompute 'sha256-…' hashes for static inline blocks. Both let those exact blocks run while everything else stays blocked.

How to use it

  1. Copy a Content-Security-Policy header value, not the full response header block.
  2. Paste it into the parser.
  3. Review each semicolon-separated directive and source list against your deployment policy.
What is CSP Header Parser?

Break a Content-Security-Policy header into its individual directives and sources for review.

How it works

SiteIndex splits a pasted Content-Security-Policy value on semicolons, then lists each directive with its allowed sources in an easy-to-scan table.

Common uses
  • Review a CSP header before deploying a security policy change.
  • Spot an overly permissive or missing directive at a glance.
  • Document the current CSP rules for a page or application.
Limitations
  • Splitting directives does not validate source expressions, simulate enforcement, or certify a policy as secure.
  • Duplicate directives and browser-specific enforcement require separate inspection.
Frequently asked questions
Where do I get a page's CSP header value?
Open your browser's network inspector, select the document request, and copy the Content-Security-Policy response header, or use the Headers Checker tool.

Related tools

Headers Checker
Review HTTP response headers for caching, content type, security, and debugging information.
SSL Checker
Check an SSL certificate's expiry date, issuer, covered hostnames, chain of trust, and TLS version for any domain.
HTTP Status Checker
Check the HTTP response for a URL and review the status, server, and redirect chain.
Website Score
Measure a public website's SEO, performance, accessibility, security, and technical health.