AI & security

Security Headers Checker

Response headers, CSP quality, and the TLS certificate underneath

105 rules covering the headers that decide what a browser will let a compromised page do: Content-Security-Policy and the quality of its directives, HSTS, frame protection, referrer policy, permissions policy, and information disclosure through server banners.

Try:

Free, no signupNo account, no card
No AI in the score986 deterministic rules
Nothing publishedYour scans stay yours
Answers in secondsQuick scan, no browser

Headers describe policy and say nothing about the connection carrying them - so this also performs a real TLS handshake. You get the negotiated protocol and cipher, and the leaf certificate's issuer, validity window, days until expiry and subject alternative names, checked against the hostname you scanned.

That last check catches the failure that takes a site down completely: a certificate that does not cover the www form, or one that expired because a renewal ran but the server was never reloaded. No header check can see either.

Why this matters

You added the headers. Are you actually protected?

Someone told you to add security headers: a compliance form, a client's IT team, a scan report with red rows on it. So you added them, and something gave you a grade. But a header can be present and still permit the exact attack it was written to stop, and the certificate carrying every one of those headers can expire on a Tuesday morning without a single header check noticing.

What it costs you when this is wrong

The whole site vanishes behind a warning
An expired certificate, or one covering example.com but not www.example.com, puts a full-page browser warning in front of every visitor. There is no partial failure and no email about it. You find out when a customer rings you.
The policy is present and the injection runs
A script-src containing 'unsafe-inline' lets injected inline script execute exactly as it would with no policy at all, and a bare wildcard source does the same for a whole class of origins. The header is there, a presence check says it is there, and the protection is not.
A guessed policy breaks the page on deploy
CSP denies by default, so any origin you missed stops loading the moment the header ships: web fonts requested from inside CSS, images from srcset, the payment script your checkout injects at runtime. The page still returns 200, so uptime monitoring stays green while the basket button does nothing.

Why run it here

CSP graded by its contents, not its presence
38 rules read what is inside the policy: 'unsafe-inline', 'unsafe-eval', 'unsafe-hashes', a bare wildcard and data: as a source are each reported on their own, alongside which directives the policy sets at all. Twenty named Permissions-Policy features, from camera and geolocation to serial and idle-detection, are reported the same way, one rule each.
Wildcard certificates matched as browsers do
The scanned hostname is checked against the certificate's subject alternative names using single-label wildcard matching, so a certificate for *.example.com is reported as not covering the bare example.com apex, and not covering a.b.example.com either. That mismatch takes a site down exactly as completely as an expired certificate, and it is easy to create when the apex and www forms are configured separately.
A starting CSP built from real requests
Every origin the page requests during a real browser load is recorded and grouped by resource type, then assembled into a draft policy covering what the page actually fetches, including the @font-face, srcset and script-injected requests that appear in no HTML attribute anywhere. It is handed over as a draft to run in report-only mode first, with a note that one page load is not every route.

This check runs on its own here, and as part of the full audit alongside the other 985 rules. Either way the findings carry their evidence and their citation, and the report is never published or kept.

How to add security headers

Add them in this order. Content-Security-Policy is the most valuable and the most likely to break something, so it goes in last and in report-only mode first.

Add Strict-Transport-Security with a max-age of at least a year, once you are certain every subdomain supports HTTPS.
Add X-Content-Type-Options: nosniff, which costs nothing and stops the browser second-guessing your content types.
Set Referrer-Policy to strict-origin-when-cross-origin so full URLs stop leaking to third parties.
Add a Permissions-Policy denying the features you do not use — camera, microphone, geolocation and the rest.
Introduce Content-Security-Policy last, deploying it as Content-Security-Policy-Report-Only first and reading the violations before you enforce it.

What happens when you run it

Enter your address
Just the domain is enough — example.com, with or without the https. No account, no card, no crawl of your whole site.
We render it like a visitor
Your page opens in a real browser and JavaScript runs to completion, so what gets audited is the page a person actually sees — not the raw HTML your server sent. A screenshot comes back with the report as evidence of exactly what we measured.
You get findings you can act on
Up to 986 checks run against that rendered page. Each finding names the rule, quotes the evidence found on your page, cites the public specification behind it, and says what to change. Nothing is a judgement call — run it twice on an unchanged page and the score is identical.

What runs this check

Real browser rendering
Live TLS handshake

Named because provenance is the product. Every finding in your report says which of these produced it, so you can check the reasoning rather than take a score on faith.

Questions

Why does my CSP score badly when I have one?: Because having a CSP and having an effective one are different. A policy containing `unsafe-inline` on script-src permits exactly the injection it exists to stop. The rules here grade directive quality, not header presence.
Do you check my certificate?: Yes - a real handshake, reading the negotiated protocol and cipher and the leaf certificate. It deliberately does not abort on an untrusted chain, because an expired or mismatched certificate is precisely the case worth reporting, and aborting would return nothing.

Also checks

This page answers these searches too — they are the same job, so they share one page rather than being split across near-identical ones:

security header test
csp checker
hsts checker
ssl checker

Other checkers

Run the security headers checker now

No signup, no credit card. Quick answers in seconds; a full audit takes about a minute.

Run a free scan

No signup. No credit card. Nothing stored but the result.

Security Headers Checker

Response headers, CSP quality, and the TLS certificate underneath

You added the headers. Are you actually protected?

What it costs you when this is wrong

The whole site vanishes behind a warning

An expired certificate, or one covering example.com but not www.example.com, puts a full-page browser warning in front of every visitor. There is no partial failure and no email about it. You find out when a customer rings you.

The policy is present and the injection runs

A script-src containing 'unsafe-inline' lets injected inline script execute exactly as it would with no policy at all, and a bare wildcard source does the same for a whole class of origins. The header is there, a presence check says it is there, and the protection is not.

A guessed policy breaks the page on deploy

CSP denies by default, so any origin you missed stops loading the moment the header ships: web fonts requested from inside CSS, images from srcset, the payment script your checkout injects at runtime. The page still returns 200, so uptime monitoring stays green while the basket button does nothing.

Why run it here

CSP graded by its contents, not its presence

38 rules read what is inside the policy: 'unsafe-inline', 'unsafe-eval', 'unsafe-hashes', a bare wildcard and data: as a source are each reported on their own, alongside which directives the policy sets at all. Twenty named Permissions-Policy features, from camera and geolocation to serial and idle-detection, are reported the same way, one rule each.

Wildcard certificates matched as browsers do

The scanned hostname is checked against the certificate's subject alternative names using single-label wildcard matching, so a certificate for *.example.com is reported as not covering the bare example.com apex, and not covering a.b.example.com either. That mismatch takes a site down exactly as completely as an expired certificate, and it is easy to create when the apex and www forms are configured separately.

A starting CSP built from real requests

Every origin the page requests during a real browser load is recorded and grouped by resource type, then assembled into a draft policy covering what the page actually fetches, including the @font-face, srcset and script-injected requests that appear in no HTML attribute anywhere. It is handed over as a draft to run in report-only mode first, with a note that one page load is not every route.

Questions

Why does my CSP score badly when I have one?

Because having a CSP and having an effective one are different. A policy containing `unsafe-inline` on script-src permits exactly the injection it exists to stop. The rules here grade directive quality, not header presence.

Do you check my certificate?

Yes - a real handshake, reading the negotiated protocol and cipher and the leaf certificate. It deliberately does not abort on an untrusted chain, because an expired or mismatched certificate is precisely the case worth reporting, and aborting would return nothing.

Security Headers Checker

You added the headers. Are you actually protected?

What it costs you when this is wrong

The whole site vanishes behind a warning

The policy is present and the injection runs

A guessed policy breaks the page on deploy

Why run it here

CSP graded by its contents, not its presence

Wildcard certificates matched as browsers do

A starting CSP built from real requests

How to add security headers

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the security headers checker now

Security Headers Checker

You added the headers. Are you actually protected?

What it costs you when this is wrong

The whole site vanishes behind a warning

The policy is present and the injection runs

A guessed policy breaks the page on deploy

Why run it here

CSP graded by its contents, not its presence

Wildcard certificates matched as browsers do

A starting CSP built from real requests

How to add security headers

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the security headers checker now