Checking HTTP security headers: eleven tools compared

Survey date: 26 October 2026. Every row in the table below was checked against the tool's own page on that date, and every link points to the source. The only two measurements we ran ourselves are flagged as such. This page does not rank tools best to worst. It ranks them by use case, because they do not answer the same question.

Three questions people confuse#

"Check the headers" covers three different jobs. The usual one is presence: does the server send Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and the rest? That is what most tools do, with a letter grade attached. One step further, you check the value: does the policy that was sent actually protect anything, or does it allow any script? What almost nobody does is context: does this site have anything to protect at that spot, and what line of configuration do you write in the stack you actually run?

Almost every tool stops at presence. A handful go as far as the value. Context is handled nowhere, and context is what decides whether the missing header concerns you at all.

The table#

Ranked by use case#

securityheaders.com stays the fastest way to get a diagnosis in English: you paste a URL, you get six headers and a letter. It reads neither cookies nor TLS, and it does not lower the grade when the CSP allows unsafe-inline.

If what you care about is the value rather than the presence, ssl.org shows raw values and rates each one, with no grade; CentralCSP does the same with a score out of 100 and a fix per finding. They are the only two in the table that rate each header of a URL scan without handing down a global grade.

In French, Kreio ranks by severity and gives an A to F grade; CheckCyber gives a score out of 100 with Apache and nginx configuration examples. The second is the more concrete on remediation, the first the more readable on prioritisation.

To track a CSP over time, CSP Evaluator judges the policy before you ship it; Report URI collects violations in production, but that is a subscription from 54.99 USD per month, not a free tool. CentralCSP sells the same monitoring.

For a TLS certificate, Qualys SSL Labs, the reference since 2009, and ImmuniWeb which adds compliance and post-quantum readiness. For the full picture, Hardenize covers DNS, email, TLS and headers, and qualifies each finding by how much it matters for your kind of site. For a published method and a French interface, MDN HTTP Observatory: its scoring documentation is public, so you can say where the grade comes from before quoting it.

What none of these tools does#

1. The grade is a judgement, not a measurement, and Mozilla says so. The Observatory documentation states: "It is difficult to assign an objective value to a subjective question such as 'How bad is not implementing HTTP Strict Transport Security?'" and adds that "the letter grade ranges and modifiers are essentially arbitrary". An A-F grade is a calibrated opinion, not a reproducible fact. That does not make it useless. It makes it non-defensible in front of a third party.

2. The site's context never enters the calculation. A five-page brochure site with no form, no login and no personal data has almost nothing to protect where the grid deducts points. Mozilla admits it: what may be unnecessary for one site might mitigate important risks for another. Hardenize is the only tool in the table that qualifies findings by site importance, and none of them asks whether you have a login form before handing you a letter.

3. "Present" is not "effective", and two tools can contradict each other on the same day. We scanned breachvex.com on 26 October 2026 at 16:34 UTC. securityheaders.com returned A, with a warning that the policy contains unsafe-inline and unsafe-eval in script-src and that the grade is capped at A. The same domain, ten seconds later, on MDN HTTP Observatory: B, 75 out of 100, 10 of 12 tests, with -20 on the CSP test for exactly the same reason. A policy that allows inline scripts is not an injection defence, and one of the two tools still rewards it. At web scale, 46.8% of the 170,057 CSP policies in the top 1 million contain unsafe-inline (Report URI, 13 June 2026 snapshot).

4. None of them tells you what will break on your site. Several hand you a fix: CheckCyber gives Apache and nginx examples, CentralCSP gives the exact value to deploy. None of them knows that your page loads Google Tag Manager, a payment iframe and an inline script generated by your framework, or that moving to Report-Only and then to a nonce will break one of the three. The configuration line for your real stack, with a warning about what it breaks, is in none of these reports.

5. None of it produces a report you can hand to someone else. MDN's own documentation warns that score modifiers change over time, so a 2025 grade no longer means the same thing in 2026. None produces an attestation: a stated scope, a method version and a validity period that you can attach to an answer for a client or an insurer.

6. A scan only sees one URL. A CSP can be served on one route and not another, and two servers behind a CDN can answer differently. ssl.org is the only one that says so on its page, and it answers by letting you scan another URL rather than by qualifying its own verdict.

Method#

Survey date 26 October 2026. For each tool: reading its public page (product description, FAQ, pricing, scoring documentation) and its methodology page where one exists. The table links point to those pages.

Two real scans were run on the same day against a domain we control, breachvex.com, on securityheaders.com and on MDN HTTP Observatory, to compare two grading systems on one configuration.

What we did not do: no large-scale false-positive testing, no speed comparison, no source-code review, no testing of paid tiers. The "what it does not measure" column comes from public pages and our own scans, not from a measurement campaign. Where a point could not be verified on the vendor's page, it was not guessed: the limit is named in the row it affects.

What we do, and what we do not claim#

BreachVex builds an automated application pentest. The promise fits in one sentence: a result only enters the priority queue if the exploit was actually executed. We have no published headers tool today, and this page does not stand in for one. It exists because the question keeps coming up, and because two tools had just contradicted each other on our own site the same day. Everything above was measured, read on the vendor page, or reproduced with a command; where something could not be checked, the limit is named in the row it affects.

What we do not claim. We do not replace Report URI for CSP violation monitoring, Qualys SSL Labs for TLS analysis, or MDN HTTP Observatory for an institutional grade. We do not prove exploitation from a missing header: a missing header is an exposure, not a demonstrated flaw. And a scanner does not replace an audit.

If this page was useful, the feedback that matters to us is simple: tell us which tool gave you a result you judged wrong, and on which site. That is what will improve the next version of this survey.