A header checker for debugging, not only for grading

Security Headers gives a site a letter grade against a specific checklist, and as an audit of that checklist it is better than this. It is also answering a different question from the one most people have when they open a header tool, which is usually not how secure am I but why is this page behaving like that.

Open the HTTP Header Checker →

Security Headers and Softland, side by side

 Security HeadersSoftland
Security header auditThorough, with a letter gradeChecked against what a well-configured site sends
Every other response headerNot the focusShown in full
Caching and content type headersOutside the gradingShown - usually the reason you are looking
RedirectsFollows to the final URLVisible as part of the response
Checking a site you do not ownYesYes - headers are public

Most header questions are not security questions

Why is the CDN still serving the old version. Why does this file download instead of displaying. Why is the page not being cached. Why did this request end up on a different URL. Why is compression not being applied. Every one of those is answered by a response header, and none of them appears on a security scorecard.

Seeing the whole set at once is what makes those diagnosable. Cache-control against the age header tells you whether an edge cache is holding a stale copy and for how long. Content-type explains a file that downloads rather than renders, and content-disposition explains the rest. A grade cannot tell you any of that, because it was never trying to.

The security headers worth having, briefly

Strict-Transport-Security, so a browser refuses to speak plain HTTP to your domain after the first visit. X-Content-Type-Options set to nosniff, so a browser does not second-guess your content type and execute something as script that you served as text. A sensible Referrer-Policy, so full URLs including their query strings are not leaked to every third party you link to. X-Frame-Options or a frame-ancestors directive, so your pages cannot be embedded invisibly in somebody else.

Content-Security-Policy is the one that matters most and the one nobody ships, because it takes real work to write and breaks the site while you get it wrong. A missing CSP is not an emergency on a page with no user input and no third-party scripts. On anything handling sessions or accepting content, it is the difference between an injected script being an incident and being a non-event.

Headers are public, which cuts both ways

Every response header is sent to anyone who requests the URL, so checking them for a site you do not own is neither an attack nor a grey area - it is reading what the server volunteers to every visitor. That makes header inspection a legitimate part of evaluating a vendor, debugging an integration, or working out how a competitor has configured their caching.

It also means your own headers are public. Version numbers in a server header, an internal hostname in a redirect, a framework name and version - all of it is readable by anyone, and all of it narrows an attacker search for a known vulnerability. Removing what you do not need to advertise is the cheapest hardening there is.

When Security Headers is the better choice

  • You want a graded audit to hand to someone as evidence, which a letter and a checklist communicate far better than a raw header list.
  • You are working through a hardening exercise and want the thorough explanation of each security header and its directives.
  • You want to track a grade over time as a measure of progress.

Frequently asked questions

Which security headers should every site send?
Strict-Transport-Security, X-Content-Type-Options set to nosniff, a Referrer-Policy, and protection against being framed. Content-Security-Policy matters most and takes the most work to get right.
What does nosniff actually do?
It stops the browser from guessing a content type that disagrees with the one you sent. Without it, a file you served as plain text can be interpreted as script if its contents look like script.
Is a missing Content-Security-Policy serious?
It depends on the page. On a static page with no user input it is low risk. On anything with sessions, forms or third-party scripts it is the control that turns an injected script from an incident into nothing.
Can I check headers for a site I do not own?
Yes. Response headers are sent to every visitor, so reading them is the same as loading the page. Nothing about it is private or restricted.

Try it yourself

Inspect response headers and spot missing security ones.

Open the HTTP Header Checker

Security Headers is a trademark of its respective owner. Softland is not affiliated with, endorsed by or sponsored by Security Headers. This comparison reflects how each product works rather than what either costs, because pricing and plan limits change; check Security Headers’s own site for its current terms.