I have a website hosted at https://example.com/mysite. If you navigate to http://example.com/mysite, you get a 404. Everything that comes in over HTTP gets 404'd.

I was dinged on a security audit because I wasn't auto-upgrading HTTP to HTTPS. According to the bug report, my site is violating HSTS because it's not upgrading HTTP to HTTPS and adding Strict-Transport-Security headers to all responses.

If my site is only available on HTTPS, though, is this actually an issue? Is there some attack vector when the site is not actually available at all via HTTP, even via redirect? I know a redirect from HTTP to HTTPS makes a MITM attack possible, but without such a redirect at all, I don't understand what the issue is.


2 Answers 2


The issue here is that you aren't providing an HTTPS-only site. An HTTPS-only site would literally not respond on port 80 at all.

When someone accesses your site using HTTP, if you send a 301 and then use HSTS, that browser will literally never connect over HTTP again unless you clear the HSTS cache. This is still subject to an attack on the initial connection, but the exposure of the data is one time per user, which is the best that you can do (unless you preload your site in browsers).

When you send a 404, the user may try to use your site over HTTP again. If they were following an HTTP link to your site, that data will be exposed, and it will be every time they do so, even if all you serve them is a 404.

Note that the exposure of the data here need not be restricted to data you serve to the user. Which pages the user requests and visits are sensitive and should always be encrypted. Additionally, HTTP accesses can be intercepted by bad actors and injected with data or otherwise modified; Southwest Airlines does this on its flights to inject a header, and Verizon injects an advertising ID. Serving a 404 just confuses the user and solves only a fraction of the problems that occur with serving data over HTTP.

The goal of HSTS is to tell the browser that your site should always be accessed over HTTPS. The goal of the 301 is to get your users to see a valid Strict-Transport-Security header (which must be served over HTTPS) as soon as possible. Together, those minimize the risk of attacks on plaintext connections.

You could literally not serve any HTTP service (port 80) at all, which would be acceptable. However, browsers still tend to default to HTTP, so this may result in users being confused as to why your site is “broken” if they don't type the protocol.


If the site sends the HSTS header in the HTTP response, than that is against the RFC.

And the RFC also states, that you "SHOULD" 301 the client to HTTPS and I honestly don't see any reason not to.

  • The only reason I can think off is if you explicitly do not want To host any http service. (So only port 443). In general though write the redirect 307/308 rule.... it takes only a minute and solves to many issues to count.
    – LvB
    Oct 21, 2020 at 17:54
  • 1
    There is a reason not to redirect HTTP to HTTPS. If you have an API-only site and you do a redirect, then people who used your API over HTTP and configured their networking library to auto-follow redirects may never realise that they're connecting to your site insecurely and would be vulnerable to sslstrip type attack (even with HSTS, which only solves that issue for subsequent connection but which may not be remembered automatically by most HTTP libraries). By rejecting the HTTP request rather than redirecting, you're forcing them to use the HTTPS from first connection.
    – Lie Ryan
    Oct 21, 2020 at 19:58

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