Security Headers Checker

What this security headers checker shows

Security headers are lines in a web server’s reply that tell the browser to switch on extra protections for the site: always use HTTPS, do not let other sites embed this page, do not guess file types, and so on. When you run a check, HostChecker asks for the home page the way a browser does. It tries HTTPS first and uses plain HTTP only if HTTPS does not answer at all. It follows up to 10 redirects, so example.com that forwards to www.example.com is judged on the page you would actually land on, and then it reads the headers of that final reply. It asks with a HEAD request, which returns the headers without the page, and tries again with a normal GET if the server refuses HEAD. It looks for six headers and reports whether each is present. Which address it asks depends on whether you enter a domain name or an IP address.

For a domain name

Enter a domain and HostChecker looks the name up, connects to it over HTTPS, and follows any redirects. The tiles give a rating, how many of the six headers are set, and the HTTP status of the final reply. The table lists each header, whether it is set, and the value the server sent. Here is an example, with what each part tells you:

• Rating is a plain count of how many of the six headers are present: 5 or 6 is Excellent, 3 or 4 is Good, 1 or 2 is Basic, and 0 is Minimal. It is not a grade of how secure the site is (see below).
• Headers set is that count, out of 6.
• HTTP status is the status of the final reply after redirects, such as 200 for a normal page. A 404 or a 403 still has headers to read, but they can differ from the ones on the pages visitors use.
• Status says whether the header is present in that reply. A grey dot with “not set” means the server did not send it. It is not drawn as an error, because a missing header is a choice to look at, not always a fault.
• Value is exactly what the server sent, such as the HSTS lifetime. The one exception is the framing row, which counts either X-Frame-Options or the frame-ancestors part of the Content-Security-Policy, and says “from Content-Security-Policy” when that is where it found it. Very long values, such as a Content-Security-Policy, are shortened with a “Show all” link.
• The line under the table says which address was checked, so you can see where the redirects ended up.

For an IP address

Enter an IP address and HostChecker connects to that address directly, with no name. That is not how people normally visit a site, so the answer can surprise you. A server that hosts many sites picks which one to show by the name in the request, and when there is none it sends a default site or a placeholder page. Many addresses redirect to a proper hostname, and the check follows that, as it does for a domain. The tiles and table are the same. The complete, unedited reply is always under “Show complete raw command output”, and it shows every header the server sent, not only the six. Here is an example, with what to look for:

• The first line is the protocol and status of the final reply. Only the final reply is shown, not the replies that came before it in a redirect.
• The six rows are built from these header names (the framing row also reads frame-ancestors out of the Content-Security-Policy line). Header names are not case-sensitive, so X-Frame-Options and x-frame-options are the same. Lines longer than 400 characters are cut short in this view.
• Everything else is for context. server may name the software, and set-cookie shows the flags on a cookie. The checker does not grade either one.

Either way, here is what this check does and does not do. It checks that a header is present, not that it is a good policy: a Content-Security-Policy that allows everything counts the same as a strict one. It reads the home page only, and other pages and error pages can send different headers. It does not check cookies, cross-origin sharing (CORS), the newer Cross-Origin-* headers, or the old X-XSS-Protection header, which modern browsers no longer use. It does not check the certificate, and it still reads the headers when the certificate is expired or wrong. For that, use the SSL Checker or Host Check. It asks from HostChecker’s server, and addresses on private networks are refused.

How to read the result

• Excellent or Good (green). Most of the six are set. That is a good sign that someone has looked at the site’s headers, but it says nothing about how well each one is configured. Open the values and read them.
• Basic (amber). One or two are set. Look at the “not set” rows below and decide which ones fit your site.
• Minimal (grey). None are set. That is common for small and static sites, and it is not a fault in itself, but the cheap ones (HSTS, nosniff, a Referrer-Policy) cost almost nothing to add.
• Could not retrieve headers. Nothing answered on HTTPS or HTTP. The site may be down, the name may not point at a web server, a firewall may block HostChecker, or the address may be private. Try Ping and DNS Lookup to narrow it down.

The rating counts these six headers because they are the ones that need no changes to the site’s own code. A high count does not make a site secure, and a low one does not make it insecure. Large, well-run sites often set only some of them, because they use other mechanisms for the rest. A site can be missing every header and have no weaknesses, and a site can send all six and still have serious bugs. Treat the headers as an extra layer of defence in depth, on top of fixing the code itself.

The six security headers and what they do

Strict-Transport-Security (HSTS)

Tells the browser to use only HTTPS for this site from now on, for the number of seconds in max-age. After the first visit, a browser upgrades any http:// link to the site to HTTPS before it makes the request, which blocks attacks that rely on a visitor starting on plain HTTP. includeSubDomains extends the rule to every subdomain, so use it only when all of them work over HTTPS. Browsers only honor the header when it arrives over HTTPS and ignore it on plain HTTP, so this check does not count it if the final reply came over HTTP. It cannot protect the very first visit. The preload option asks to be built into browsers’ lists to cover that, and it needs a max-age of at least one year and includeSubDomains. Treat preloading as a long commitment, because it takes a long time to undo. A common value is max-age=31536000; includeSubDomains. Start with a small max-age while you test, and raise it once everything works.

X-Frame-Options and frame-ancestors (clickjacking)

Controls whether other sites may show your page inside a frame. Clickjacking hides your page under a harmless-looking one and tricks visitors into clicking on it. The useful values are DENY (never in a frame) and SAMEORIGIN (only frames from your own site). A third value, ALLOW-FROM, is obsolete and modern browsers ignore it. The newer way to say the same thing is the frame-ancestors directive of a Content-Security-Policy, which is more flexible, and the standard says that when both are sent, browsers should follow frame-ancestors and ignore X-Frame-Options. This check counts either one. If the server sends X-Frame-Options, the row shows that value. If it sends only a Content-Security-Policy with frame-ancestors, the row shows that directive and says it came from the Content-Security-Policy. Like the other rows, it checks that the protection is present, not that it is strict, so frame-ancestors *, which lets every site frame the page, still counts. X-Frame-Options only works as a real HTTP header. A <meta> tag does nothing for either one.

X-Content-Type-Options (MIME sniffing)

The only value is nosniff. Without it, a browser may look inside a file and guess a different type from the one the server declared, so an uploaded file served as plain text could be run as a web page and its script executed. With nosniff, the browser trusts the declared type, and refuses to load a script or stylesheet that does not have the right one. It only works if your server declares the correct Content-Type on every file, which most do. It is one of the safest headers to add.

Content-Security-Policy

Lists which sources the page may load scripts, styles, images, and frames from, and the browser blocks everything else. It is the most effective of the six against cross-site scripting (XSS), where an attacker gets their own script to run on your page, and also the hardest to add, because a policy that is too tight breaks the site. A policy such as default-src 'self' allows only your own origin, which suits a simple site and breaks one that loads fonts, analytics, or widgets from elsewhere. Adding 'unsafe-inline' to the script rules allows inline scripts again, which is the thing XSS attacks depend on, so it removes most of the protection. Nonces and hashes are the safer way to allow scripts you wrote. You can try a policy without enforcing it by sending it as Content-Security-Policy-Report-Only, which reports problems without blocking anything. Present is not the same as good. This check does not read the policy, so one that allows everything counts the same as a strict one.

Referrer-Policy

Controls how much of your page’s address is sent to other sites in the Referer header when a visitor follows a link or loads a resource. Full addresses can include things like search terms or private tokens. Browsers that follow the current rules treat a missing header as strict-origin-when-cross-origin, which sends the full address within your own site and only the site name to others, and sends nothing when going from HTTPS to HTTP. Setting it yourself makes that behavior certain, including in older browsers. For more privacy, same-origin sends nothing to other sites, and no-referrer never sends anything. Avoid unsafe-url, which sends the full address everywhere.

Permissions-Policy

Turns off browser features your site does not use, such as the camera, microphone, or location, for your page and for anything embedded in it. For example, camera=(), microphone=(), geolocation=() disables all three. It replaced the older Feature-Policy header, which this check does not look for. Support differs between browsers, so treat it as an extra layer, not a guarantee.

How to add security headers

Headers are added in the web server, the host’s control panel, or the CDN in front of the site, not in the page’s HTML. Add one at a time, test the site, and run this check again to confirm.

• nginx: add_header X-Content-Type-Options "nosniff" always; in the server block. Use always so it is also sent on errors and redirects. Note that if a location block has its own add_header lines, those replace the ones from the level above instead of adding to them, which is the usual reason a header “disappears” on part of a site.
• Apache: Header always set X-Content-Type-Options "nosniff", which needs mod_headers to be enabled.
• A CDN or managed host: look for a setting for response headers or custom headers in its dashboard. This check sees what the visitor gets, whichever layer added it.
• The application: many web frameworks set some of them for you, often through a security middleware or plugin.

Use the examples from the section above for the other headers. After a change, it can take a moment for a CDN or a cache to serve the new reply.

Common problems and fixes

The header is set in the config, but the check says it is not set

The check judges the final page after redirects, at the home page. Common causes: the header is only added to some paths; the nginx location inheritance above; a server rule that adds it only to successful replies, not to a redirect or error page; or a CDN or cache serving an older copy. The raw output shows what the server really sent.

Strict-Transport-Security is sent but not counted

The final reply came over plain HTTP, where browsers ignore the header. Make the site redirect HTTP to HTTPS, and send HSTS from the HTTPS reply. Host Check shows the redirects.

The result is for a different page or name than I expected

The line under the table says what was checked. A domain that redirects to www, to a login page, or to another site is judged on where it ends up. For an IP address, a shared server may show its default site.

The framing row says “from Content-Security-Policy”

The site has no X-Frame-Options header and prevents framing with the frame-ancestors directive instead. That counts. Browsers that understand frame-ancestors use it, and X-Frame-Options only matters for browsers that predate it, so you can add it as well if you want to cover those. It does no harm.

Could not retrieve headers

No web server answered. Check that the name is right with DNS Lookup, then that the host is up with Ping. A web application firewall can also refuse requests from unfamiliar addresses, and then the site works for visitors while this check gets nothing.

Frequently asked questions