Should I return an HSTS header for 404 error pages?

Question

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.

Answer 1

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" />
</site>

Before that, you had to

• do the HTTP to HTTPS redirection separately

  <?xml version="1.0" encoding="UTF-8"?>
  <configuration>
      <system.webServer>
          <httpRedirect enabled="true" 
                        destination="https://contoso.com" 
                        httpResponseStatus="Permanent" />
      </system.webServer>
  </configuration>
  

• add the header using <customHeaders>:

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

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

Answer 2

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.