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.

Free · no sign-up · updated

Runs entirely in your browser. Nothing you enter leaves this page.

requests since opened: 0
Verify it yourself

This page is served with a security policy your browser enforces: it cannot open connections or load anything from other sites — not even to us.

  1. Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
  2. Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
  3. See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
  4. Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).

tools v0.9.1 · build 0efa119

How to use
  1. 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.
  2. Read “Fix these” first, then the policy table and cookie flags.
  3. Copy the missing headers for your server, or the report for a ticket.
Examples:
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