HTTP Security Headers Checker

Where to start, if you are starting

The headers are not equally valuable and they are not equally risky to deploy. In the order that gives the most protection for the least chance of breaking something:

The last row is the one that matters most and the one that takes actual work. Everything above it is an afternoon.

HSTS, and the one irreversible decision in it

Strict-Transport-Security tells a browser to use HTTPS for this host for the next max-age seconds, no matter what. It closes a narrow but real gap: a visitor typing example.com makes one plaintext request before your redirect, and that request can be intercepted.

Strict-Transport-Security: max-age=31536000; includeSubDomains

includeSubDomains matters more than it looks. Without it, a subdomain served over HTTP can still set cookies for the parent domain. With it, every subdomain must be HTTPS-only or it becomes unreachable — so check before adding it.

The preload directive is the decision to think hard about. It gets your domain baked into browsers’ shipped preload lists, so HTTPS is enforced before the first request ever happens. It is also effectively irreversible: removal requires a request to the list maintainers and then waiting for browser releases to roll out, which is months. Excellent once you are certain; a bad thing to add casually.

CSP: report-only is not optional

A Content-Security-Policy is the only header here that stops injected script from running, and it is the only one that can take your site down. Both facts follow from the same property: it restricts what may load.

Deploy it in report-only mode with a collector and leave it for a few weeks of real traffic. What you will find is not what you expected from reading the code — there will be a font host you forgot, a payment iframe, and frequently a script injected at the CDN edge that appears in no source file anywhere. That last category is precisely what report-only exists to surface.

Content-Security-Policy-Report-Only: default-src 'self';
  script-src 'self'; object-src 'none'; base-uri 'self';
  report-uri /csp-report

Two things that undo most of the benefit. 'unsafe-inline' in script-src permits exactly the injected inline script the policy exists to stop — nonces or hashes are the way out. And 'unsafe-eval' re-enables eval and its relatives, which some older framework builds still need. The checker flags both as weakening rather than as absent, because a policy with them is still doing useful work; it is just not doing the main job.

Headers whose advice has expired

• X-XSS-Protection — controlled a browser filter that has been removed from every major browser, and which in its day could itself be manipulated to break pages. It is not a header to set in 2026.
• Expect-CT — obsolete. Certificate Transparency is now enforced unconditionally, so the header does nothing.
• Feature-Policy — renamed to Permissions-Policy, with different syntax. Only the new name is honoured.
• Public-Key-Pins — removed from browsers, and rightly. A mistake in it bricked your domain for the pin lifetime with no way to recover.

What this does not check

One page, one response. It reads the headers on the final response after following redirects, and stops there. It does not crawl the site, evaluate JavaScript, test your TLS configuration or check cookie flags — and different paths on the same site can send entirely different headers, so checking the homepage tells you about the homepage.

For TLS configuration specifically, Qualys SSL Labs is the established tool and is thorough. For the certificate itself, this one reads what a host actually presents.