Security Headers, at securityheaders.com and run by security researcher Scott Helme, is one of the best-known free tools in this space. You give it a URL, its own server fetches the live response, and it hands back a single letter grade -- A+ down to F -- summarising the site's overall header hygiene. It needs nothing installed and no account, and for a quick outside read on a public site it is a genuinely useful first stop.
This checker does a narrower, differently-shaped job. It is a single zero-dependency Node CLI:
node check.mjs <url> sends one request from your own machine
(not from a third party's server) and classifies the response's frame-protection and
Content-Security-Policy headers into named misconfiguration patterns -- missing clickjacking
protection, an X-Frame-Options: ALLOW-FROM value every current major browser silently
ignores, a CSP script-src allowing 'unsafe-inline' with nothing overriding
it, a wildcard script source, CSP shipped only as report-only, and a missing
Strict-Transport-Security header -- rather than folding everything into one grade. It
has no server-side component of its own: the browser page here only renders a report from JSON you
already have.
| What you are trying to do | Where to do it |
|---|---|
| Get a quick, single-grade outside read on a public site's overall header hygiene. | Security Headers -- one paste, one grade, no install. |
| Check a private, password-protected, or staging URL your machine can reach but a public third-party server cannot. | This checker -- the CLI makes the request from wherever you run it. |
Know exactly why a finding is a finding -- for example that ALLOW-FROM looks like frame protection but no current browser honours it, or that frame-ancestors does not inherit from default-src the way script-src does. |
This checker -- named patterns and the exact header behind each one, not a single grade. |
| Make sure the URL and response headers you're checking never pass through any third party at all. | This checker -- the request goes straight from your machine to the target; the browser page only parses JSON you paste into it locally. |
| Gate a deploy in your own CI on a specific clickjacking/CSP/HSTS regression with an exit code. | This checker -- node check.mjs <url> exits non-zero on a danger finding. |
| See how the full, broader set of modern security headers (Referrer-Policy, Permissions-Policy, and others this checker doesn't cover) reads on a public site, in one view. | Security Headers -- this checker only covers frame protection, CSP strength, and HSTS. |
These compose rather than compete. A reasonable habit is Security Headers for a fast outside sanity check on a site that's already public, and this checker wired into your own CI against your own staging environment, where a regression in the specific patterns it covers turns a build red the day it lands rather than being caught later by a public scan. Neither one replaces the other.
They can both be useful, and for a quick outside read on a public site, Security Headers is a reasonable first stop. It is a free, well-known web scanner: you give it a URL, its own server fetches the response, and it returns a single letter grade (A+ down to F) based on which security headers are present. This checker does something narrower and more specific: a local Node CLI you run yourself sends one request to a URL you name, from your own machine, and classifies the frame-protection and CSP headers into named patterns -- including the ALLOW-FROM trap and the frame-ancestors/default-src fallback distinction -- rather than a single overall grade. Reach for Security Headers for a fast outside opinion on a public site; reach for this when you want a plain-English reason for a clickjacking or CSP-strength finding, or a check you can run unattended against a private staging URL.
Being free is not the difference. The differences are who makes the request and what the output actually explains. Security Headers' own server fetches your URL, which is fine for a public production site but means a private, password-protected, or staging URL either can't be scanned or has to be reachable from the public internet for a third party to reach it. This checker's CLI runs on your own machine (or your own CI runner) and sends the request itself -- it can point at localhost, a VPN-only staging host, or anything else your machine can reach, and nothing about the target URL or the response ever goes through this site or any other third party. And where a grade tells you a header is missing, this checker's report names the exact header and the specific rule it fails -- for example that an X-Frame-Options: ALLOW-FROM value is present but silently ignored by every current browser, or that a CSP's unsafe-inline is a real gap because no nonce or hash overrides it.
Because a browser page that could fetch any URL you typed into it would itself be a server-side request forgery risk, and it would rule out exactly the private and staging URLs a developer most wants to check before a site goes public. Security Headers solves that by making the request from its own server, which is the right tradeoff for a public site you're happy for a third party to fetch. This checker makes the opposite tradeoff: the request comes from a small local CLI you run yourself, and the browser page here only renders the JSON you already have -- nothing typed into it is fetched by this site.
No. This site is not affiliated with, endorsed by, or sponsored by Scott Helme or Security Headers (securityheaders.com), named here only to describe what this checker is and is not. What Security Headers currently checks and how it grades are described on its own site -- check there for what it covers today.
Only point either tool at a system you own or are authorised to test. That rule is unchanged by which one you pick.