I setup our .NET web application so that it has HSTS enabled. I verfied this by going to https://gf.dev/hsts-test and put in our URL and it shows that HSTS protection is there.

The result shows:

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

However, our client comes back saying it is still not the case. They told us while our main URL is HSTS enabled, the test vector URL is not.

For example:

  1. Go to https://gf.dev/hsts-test
  2. Put in https://nvisium.com and click Test Header
  3. Result shows it is HSTS enabled.
  4. Do the test again but put in https://nvisium.com/test.xml (test.xml does not exist)
  5. Result shows it is not HSTS enabled.

If I put the URL to an existed resource that it passes the HSTS test.

My question is do they have a point? or is this a false positive test in one of the Penetration test software they use?

Playing devil's advocate, I can only argue that if you request a non-existence resource, the web site still sends a response back and that it does not force the client to use hsts.

  • 1
    Hi Fylix, I've edited your post to make the title a question. If you don't like my change you're welcome to edit it yourself or revert back my changes. Welcome! May 15, 2020 at 12:13
  • Thank you Conor, you made the question much clearer; I was going to include that 404 question idea into my question after reading ZT's explanation, but you already did it for me :)
    – Fylix
    May 15, 2020 at 14:21
  • 1
    Related: security.stackexchange.com/questions/122441/…
    – jub0bs
    Mar 4, 2021 at 16:25

2 Answers 2


First retrieving arbitrary non-existing resources like /test.xml isn't within normal operation of your site, and therefore the problem doesn't exist anymore after the browser has seen the HSTS header somewhere (or preloaded it), as it causes upgrade to HTTPS on hostname level (and domain level with includeSubDomains).

Also, it doesn't make a huge difference whether an attacker uses URLs that would lead to 404 responses instead of 200, as if there's no cached HSTS the attack would work similarly with both. Complaining about this test failing demonstrates lack of understanding how HSTS works and what's it for.

That said, making your web server add the HSTS header instead of the application makes the probability of seeing the header a bit higher on a few rare border cases like this, while HSTS preloading would handle this while it also helps those who have never visited the site before.

HSTS Preloading

As you already have includeSubDomains, you should be ready for preloading:

  1. Add preload to the header:

    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  2. Submit your site for preloading at https://hstspreload.org/

Adding the HSTS header with Microsoft IIS

Since IIS 10.0 1709 there has been native support for HSTS, meaning you could use <hsts>:

<site name="Contoso" id="1">
    . . .
    <hsts enabled="true" max-age="31536000" 
          includeSubDomains="true" preload="true" 
          redirectHttpToHttps="true" />

Before that, you had to

  • do the HTTP to HTTPS redirection separately

    <?xml version="1.0" encoding="UTF-8"?>
            <httpRedirect enabled="true" 
                          httpResponseStatus="Permanent" />
  • add the header using <customHeaders>:

    <?xml version="1.0" encoding="UTF-8"?>
                    <add name="Strict-Transport-Security" 
                         value="max-age=31536000; includeSubDomains; preload" />

As it's Microsoft Windows, there are GUI equivalents for both, here in the same picture:


  • Thank you Esa, like ZT you not just gave the answer but provided the support information which makes it even more clearer and it helps me learn new concept in it.
    – Fylix
    May 15, 2020 at 14:39

Suppose attacker tricks victim to click on link to your site, browser uses http, attacker in strong network position intercepts and sends malicious content and makes victim believe content came from your site.

How would HSTS help? If the victim visited your site before, their browser has an HSTS "flag" for the domain, and clicking the link would make the browser use https instead, foiling the attack. But only if the victim has visited the site before!

What about victims who did not visit the site before, or visited the site too long ago? This is what HSTS Preload is for. I recommend adding your site to HSTS Preload list. This would foil the attack regardless of presence of HSTS header on 404 error page.

Note, HSTS on 404 error page doesn't affect the attack as described. Whether the link provided by attacker leads to 404 or not doesn't matter - the attacker can intercept and replace the response either way. What matters is whether this browser has visited your site before (within the time limit) or not, and whether you have HSTS Preload (and updated browser) or not.

With nginx webserver, there is a way to add HSTS response header to error pages too, the optional "always" argument to "add_header". I don't know how to do that with IIS or whether it's even possible with IIS, but maybe it is. In your place, I would fix this, but I don't see how it's a security problem.

  • Thanks ZT, that is a really good explanation and I applicate your time to write it. You are right, I am on IIS and most of this configuration is in my .NET config file. I will follow your recommendation to start the process to apply for HSTS preload. I actually tested out with some site like facebook.com and gsa.gov and on those site, even non-existence resources url came back as HSTS enabled, I'm unsure this relates to Preload or not.
    – Fylix
    May 14, 2020 at 20:10
  • The HSTS in the response that you see is not related to preload. Preload affects whether a browser "rewrites" the first ever request to that domain that it performs in its life from http to https, before ever talking to that server. On a new install of Windows in a VM.
    – Z.T.
    May 15, 2020 at 5:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .