HSTS doesn't show active on securityheaders.com

We recently added HSTS on several of our domains that redirect to our primary domain, but when we verify them on securityheaders.com (and uncheck Follow Redirects) that site indicates that HSTS is not present. We did see the post mentioning the security headers worker template for CloudFlare but that did not resolve our issue. Has anyone been able to resolve this type of issue?

If you blocked their request, you might not get that header.

If you post one of the affected domains, we can test.

As a note, if it is a block, then you’re most likely blocking the HSTS Preload site as well, if you intend to use that.

Are you testing on HTTP or HTTPS?

HSTS is ignored over HTTP, so you can only test it on HTTPS. Cloudflare don’t add the header on HTTP responses.


Here’s the situation. When running a test on https://securityheaders.com/ without specifying HTTP or HTTPS for the domain: exportcorporation.com (or with the www. prefix) and also having the follow redirects option unchecked, the test comes back with the R grade because without the protocol or the follow redirects option enabled it assumes the request is an HTTP request. We are trying to see if there is a way to get the HTTP score to be the same as the score when testing over HTTPS.

HSTS seemed like it may be one way to help with this. HSTS is enabled for the domain specified above. Based on Michael’s response it seems like HSTS may not be able to help us in this regard. If there are any suggestions on what we could do I would appreciate it.

It sounds like you’re deliberately trying to not do an HSTS check by unchecking Follow Requests.

To “qualify” for the HSTS preload list (hstspreload.org), your HTTP endpoint needs to redirect to HSTS. (their requirement)

And here’s the RFC “should” statement, which sounds like they wanted to say “must”, but couldn’t for various reasons:

Cloudflare’s HSTS implementation is correct.

What are you really trying to accomplish?

We are trying to see if when we test the security headers like this:

that the results would be like they are when the follow redirects option is enabled like this:

We were hoping that by adding HSTS that if we did the test on the security headers website like in the first image that it would default to the HTTPS version of the domain rather than the HTTP version. Maybe that’s not possible to do in this case?

As Michael pointed out, you don’t get HSTS headers over a non-HSTS connection. Nor should that be allowed. If you did that on a site that did not support HTTPS, a browser would never be able to load the site. It would refuse HTTP and insist on a connection that doesn’t exist.

Your test is deliberately avoiding HTTPS and then asking if HTTPS works. It should follow redirects, just as a browser should. Then you’ll get a real world result.


Other than getting an A+ grade, is there a real world problem you are trying to solve? If you want to tell browsers to use HTTPS by default, do the redirect.

It is prohibited as @sdayman points out:

An HSTS Host MUST NOT include the STS header field in HTTP responses
conveyed over non-secure transport.


There’s nothing wrong with chasing a A+ grade either, but you can’t expect to get that with the test misconfigured.

Browsers follow redirects, HSTS requires a redirect to https:// to be effective, cannot be served on a http:// request as noted above, so everything is working correctly here.

There actually are some edge cases where it makes sense to use HSTS without a 301/302 http to https redirect, but it’s rare, and you’ll be accepting insecurity as a trade off. Imagine you have a site that needs to accept http traffic for legacy reasons, which is common for software update systems that have their own signatures. But HSTS is still useful because once a user hits HTTPS once, you want them to stay there leaving http for the legacy stuff. And loading an image from https should be enough for the browser to notice and learn HSTS for future requests.

But this is not secure, and rightly will not get a high rating as a clever MITM could take advantage of it in a way that is less likely if you use a proper 301.

I doubt anyone here is doing stuff like this though, so security checking tools should be following redirects like any normal browser does.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.