Security Headers & CSP Analyzer
Paste a site’s response headers or its Content-Security-Policy and see what is missing, what is misconfigured and how to fix it — HSTS, CSP, framing, cookies, CORS and more.
How to use
- Paste the response headers (curl output or a DevTools copy), or just a policy — or use “Get the headers from a site” for a ready command.
- Read “Fix these” first, then the policy table and cookie flags.
- Copy the missing headers for your server, or the report for a ticket.
Get the headers from a site
This page cannot connect to sites. Run this command, then paste its output in the box above. Or copy the response headers from your browser’s developer tools (Network tab → the page → Headers).
The headers that matter most
For a web page, four headers carry most of the protection. Strict-Transport-Security keeps browsers on HTTPS; Content-Security-Policy limits what scripts can run, the main browser-side defence against cross-site scripting; X-Content-Type-Options: nosniff stops browsers guessing file types; and frame-ancestors (or X-Frame-Options) stops clickjacking. Cookie flags — Secure, HttpOnly, SameSite — decide whether a session survives an XSS or a network attacker. The rest refine these, and the analyser marks them as notes rather than problems.
Strict CSP versus allow-lists
Most policies list the hosts scripts may come from. A 2016 Google study of real-world policies found the large majority of such allow-lists could be bypassed, usually through a trusted CDN that serves anyone’s code or an endpoint that runs attacker-chosen callbacks. A strict policy instead allows only scripts carrying a per-response nonce or a known hash, plus 'strict-dynamic' for what they load. That is why the analyser flags public CDNs and wildcards, and rates nonce and hash policies as strict.
Rolling out a policy safely
Send the policy as Content-Security-Policy-Report-Only first: nothing is blocked, and every violation appears in the browser console or your report endpoint. Fix or allow what legitimately breaks, then switch to enforcing. Static sites can use hashes instead of nonces — this site’s pages carry a script-src built from SHA-256 hashes of their own inline scripts, which you can check with this tool.
Common questions
How do I check a website’s security headers?
Run the command from “Get the headers from a site” (curl, on any OS) or copy the response headers from your browser’s developer tools, then paste them here. Nothing is sent anywhere: the page is locked so it cannot connect.
What makes a Content-Security-Policy weak?
Allowing 'unsafe-inline' scripts without a nonce, allowing whole schemes like https: or data:, or trusting public CDNs such as cdn.jsdelivr.net that serve anyone’s code. A nonce with 'strict-dynamic' avoids all three.
Do APIs need security headers?
Fewer of them. A JSON API should send HSTS and nosniff, and a tiny CSP (default-src 'none'; frame-ancestors 'none'). Switch “Check as” to API to see only the checks that matter.
Known limitations
- Checks the headers you paste, not the live site.
- Cookie values and Cookie/Authorization headers are dropped, never shown.
- The CSP bypass list covers well-known hosts, not every risky one.
- Browser extensions can read any page — use a private window for sensitive data. How the lock works
Related reading on CipherMind
Standards & references
- W3C Content Security Policy Level 3 (opens in a new tab)
- RFC 6797 — HTTP Strict Transport Security (opens in a new tab)
- OWASP HTTP Headers Cheat Sheet (opens in a new tab)
- Google — strict CSP (nonces and strict-dynamic) (opens in a new tab)
- RFC 6265bis — cookies (SameSite, prefixes) (opens in a new tab)
- Fetch standard — CORS (opens in a new tab)
- W3C Permissions Policy (opens in a new tab)