SecurityHeaders.com Alternatives: What Each Header Scanner Actually Checks

SecurityHeaders.com is the usual first stop when someone wants to know whether a site sends the right security headers. You paste a URL, it fetches the page, and a grade from A+ down to F comes back with a list of what is missing. It is a Snyk project these days, and it is still free.

A single letter hides a lot, though. Every scanner decides which headers count, how much each is worth and what a weak value costs, and those decisions differ. So rather than a ranked list of look-alike sites, this post sorts the free alternatives by what they actually check, which is the question that decides which one you need. We build three of the tools mentioned below, so we have tried to be as plain about their limits as about anyone else's. If you want a refresher on what the headers themselves do first, start with our guide to HTTP security headers.

What SecurityHeaders.com checks#

It looks for six response headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. The report shows which are present and which are missing, prints the raw headers with a short note on each, and adds a list of "upcoming headers" such as Cross-Origin-Embedder-Policy that are worth knowing about but do not affect the grade.

The part people skip is the warnings section. Having a header is not the same as having a useful one, and the scanner caps the grade when a value undermines it. When we ran it against this site in October 2026 it returned an A rather than an A+, with the note "Grade capped at A", because our script-src directive includes 'unsafe-inline'. That is a fair call: 'unsafe-inline' lets inline scripts run, which is the main thing a CSP exists to stop. Read the warnings before you read the letter.

What it does not do is look past the response headers of one page. It does not judge your cookies, test the redirect from HTTP to HTTPS, or look at your TLS configuration. For those you need something else.

MDN HTTP Observatory: the broadest second opinion#

Mozilla's Observatory now lives on MDN. The new HTTP Observatory launched there on July 2, 2024, and the old Mozilla Observatory, which also bundled TLS and SSH tests, was retired that September. If an old tutorial points you at the original site, the MDN version is its successor.

It covers the same headers and then goes further. Its tests include cookies, cross-origin resource sharing, the redirection from HTTP to HTTPS, Subresource Integrity, and Cross-Origin-Resource-Policy. Cookies are the important addition. A session cookie set without the Secure or HttpOnly attribute is a real weakness, and a scanner that only reads the six headers above will never see it.

The scoring works differently too. Every site starts at 100, penalties come off first, and bonus points are added only if the score is still 90 or higher, up to a maximum of 145. Anything from 100 up is an A+. MDN publishes its grading chart and the modifiers for each test, so when you lose points you can see which test cost them.

Our HTTP headers checker#

Our HTTP headers checker grades the same six headers on a 100-point scale: up to 20 points each for Strict-Transport-Security and Content-Security-Policy, and 15 each for the other four. Instead of capping the grade, it deducts points for weak values. A CSP with 'unsafe-inline' in script-src (or in default-src when there is no script-src) loses 5, 'unsafe-eval' loses 5, and a * wildcard loses 10. A Referrer-Policy of unsafe-url earns nothing, because it hands the full address of the page, query string included, to every site a visitor moves on to. Every point gained or lost appears in the breakdown, so the grade is never a mystery.

It also follows redirects itself, up to five hops, and lists each one with its status code, so you can see whether http:// goes straight to the final https:// address or wanders through several stops first. The grade is based on the final response. It parses the CSP into its directives, translates Permissions-Policy into plain lines such as "Blocked for all origins", and checks whether the HSTS header meets the preload requirements.

Its limits are the same kind as SecurityHeaders.com's. It makes one GET request to one URL from Cloudflare's network, so it sees what an anonymous visitor sees and nothing behind a login. It only connects on ports 80, 443, 8080 and 8443, and it does not score cookies or the cross-origin isolation headers. For those, use the Observatory.

Going deeper on one header#

A general scanner tells you a header exists and flags the obvious problems. When one header is the issue, a specialist tool does better.

Content Security Policy. Google's CSP Evaluator is the reference here. You paste a policy and it highlights weaknesses, including subtle bypasses that let script run even though the policy looks strict, and its checks are based on a large-scale study of real policies. Our CSP analyzer works from the other end: give it a domain and it fetches the enforced header, any Content-Security-Policy-Report-Only header, and a policy set in an HTML <meta> tag, which a scan of response headers alone will not see. It also has a paste tab for trying a policy before you deploy it. Our explainer on Content Security Policy covers the directives themselves.

HSTS. The authority is hstspreload.org, which handles submissions to Chrome's preload list. To be accepted, a site must serve a valid certificate, redirect HTTP to HTTPS on the same host, serve every subdomain over HTTPS, and send an HSTS header with a max-age of at least one year (31536000 seconds) plus the includeSubDomains and preload directives. Our HSTS preload checker reads your header against those rules and shows the domain's current status from hstspreload.org in the same view, though it does not test the HTTP-to-HTTPS redirect. Before you submit anything, read the warning on hstspreload.org itself: a domain can be removed, but the change takes months to reach users. Our post on HSTS preloading explains why that makes it a commitment.

internet.nl: headers as part of a bigger test#

internet.nl, an initiative of the internet community and the Dutch government, runs a website test that covers IPv6, DNSSEC and the HTTPS connection as well as headers. Its security options section checks X-Frame-Options, X-Content-Type-Options, Content-Security-Policy and Referrer-Policy, and looks for a security.txt file, the format defined in RFC 9116 that tells researchers how to report a vulnerability to you. No other scanner on this page checks for that file, and it is a cheap thing to add. Use internet.nl when you want headers judged alongside the rest of a site's setup rather than on their own.

The free tools already on your machine#

Every scanner above reads something you can read yourself. With curl:

curl -sS -D - -o /dev/null https://example.com/

That makes an ordinary GET request, prints the response headers and throws the body away. The more familiar curl -I sends a HEAD request instead, and a server or framework can answer HEAD with a different set of headers than GET, so a header can look missing when it is not. Use GET when you are checking what visitors receive.

Browser developer tools reach further than any online scanner. Open the Network tab, reload, and click the document request, and you see the headers your browser actually received, including on pages behind a login and on the API responses the page fetches. Online scanners only see what an anonymous visitor gets from one URL. If your dashboard or account pages are what you care about, this is the free check that reaches them.

When the grades disagree#

Run one site through three scanners and you can get three different letters. That is usually not a bug. The common reasons:

• Different header sets. The Observatory scores cookies and Subresource Integrity. SecurityHeaders.com and our checker do not.
• Caps versus deductions. 'unsafe-inline' caps the SecurityHeaders.com grade at A, while our checker takes 5 points off the CSP score, so the same headers can come out A on one and A+ on the other.
• Different URLs. One scanner followed the redirect to the www address and another graded the redirect response itself. Check the final URL in each report before comparing.
• Out-of-date expectations. X-XSS-Protection is the usual example. MDN marks it deprecated and warns that it can create vulnerabilities on otherwise safe sites. Its advice is to rely on CSP and, if you send the header at all, to send X-XSS-Protection: 0. internet.nl has removed its test for it. A scanner or audit checklist that still marks you down for leaving it out is behind the times.

The grade is a summary for people who will not read the report. If you are the one fixing the site, read the report.

Which tool for which question#

• "Are the basics in place?" SecurityHeaders.com or our headers checker.
• "Are our cookies and cross-origin settings right?" MDN HTTP Observatory.
• "Is this CSP actually stopping injected script?" Google's CSP Evaluator, plus our CSP analyzer to see every policy a page sends.
• "Can we preload HSTS?" hstspreload.org, with our HSTS checker for the header itself.
• "Do we publish a security.txt?" internet.nl.
• "What do the logged-in pages send?" Your browser's developer tools.

None of these replaces the others. A sensible routine is one broad scanner, one specialist for whatever it flags, and a look in developer tools for the pages no scanner can reach. Headers are a small part of a site's security, but they are one of the few parts anyone can check from outside in a minute, so it is worth getting them right.