Security Headers Checker

Sends one real HTTP GET request to a URL you choose and classifies the response's frame-protection and Content-Security-Policy headers into well-documented misconfiguration patterns: missing clickjacking protection, X-Frame-Options: ALLOW-FROM (a value every current browser silently ignores), a CSP script-src allowing 'unsafe-inline' with no nonce or hash to override it, a CSP wildcard script source, CSP shipped only as report-only, and a missing Strict-Transport-Security header. Only point it at a system you own or are authorised to test.

1. Run the CLI against your site

Node.js, no dependencies to install:

node check.mjs https://example.com --json

Get check.mjs, probe.mjs, and analyze.mjs from the repo — plain Node, nothing to install. It only ever talks to the URL you pass; nothing goes through this site.

2. Paste the JSON output here

Paste the JSON from step 1 and click Check.

Common questions

What does a missing frame-ancestors or X-Frame-Options header let an attacker do?

Without either header, any site on the web can load your page inside an iframe and overlay it, tricking a visitor into clicking a button on your page while believing they're clicking something else -- clickjacking. It can turn a 'log in with Google' click, a funds-transfer confirmation, or a cookie-consent toggle into an action the visitor never meant to take.

Why does X-Frame-Options: ALLOW-FROM show up as a danger finding instead of protected?

Every current major browser engine dropped support for the ALLOW-FROM value once CSP2's frame-ancestors directive shipped as the replacement. A response sending it looks protected in a raw header dump, but no browser in real use today actually honours it -- the page has no frame protection at all unless a CSP frame-ancestors directive is also present.

Does CSP frame-ancestors inherit from default-src the way script-src does?

No. Most CSP fetch directives fall back to default-src when they're not explicitly set, but frame-ancestors is a navigation directive and the spec does not give it that fallback. A policy of default-src 'self' alone provides zero clickjacking protection -- frame-ancestors has to be spelled out on its own. More background: why X-Frame-Options: ALLOW-FROM doesn't protect you anymore.

Why does 'unsafe-inline' only count as a finding when there's no nonce or hash?

CSP2 and later browsers ignore 'unsafe-inline' entirely whenever a nonce-source or hash-source is also present in the same directive -- it's kept in the header only so CSP1-era browsers still get some protection. So a script-src carrying both a nonce and 'unsafe-inline' is correctly configured for every browser that matters today; this tool only flags 'unsafe-inline' when nothing overrides it.

Why does this need a CLI instead of just checking a URL I type into the page?

Nothing stops a browser page from making the request itself for a same-origin target, but checking an arbitrary third-party URL from inside a browser tab runs into the same CORS and mixed-content restrictions the page you're checking is designed to resist -- and a page that could reach any URL you type would itself be a server-side request forgery risk. A small local CLI with no such restriction, run from your own machine, is the same shape every other tool in this class (curl, securityheaders-style scanners) uses.

Does a clean report mean the site has no security-header issues?

No. This checks a specific, well-documented set of frame-protection, CSP-strength, and HSTS patterns from one response -- it is not a full security assessment, does not crawl other pages on the site, and cannot see a misconfiguration this tool's checks don't happen to cover (Permissions-Policy and Referrer-Policy, cookie flags, and Subresource Integrity, for instance, are out of scope here -- see referrer-permissions-policy-check for the first two and sri-check for the last). Treat a clean report as evidence about these specific patterns, not a determination that the site is secure.