If I already have done a 301 redirection from all the HTTP inner pages to HTTPS, why should I use HSTS as well?

6 Answers 6


Let's look at the scenario with a 301 redirect first. The victim sends a request to http://example.com (as pointed out in comments, this could because of SSLStrip or because the user just entered example.com in the URL bar and browsers default to HTTP). If there is no MitM attack they get a 301 response back, and is redirected to https://example.com. But if there is a MitM, the attacker can just choose not to send the 301, but instead serve a (possibly modified) copy of the site over HTTP.

The weak point here is that an initial HTTP connection (without TLS) is made, and the attacker can modify that traffic. However, if you had used HSTS the browser would know (assuming that the victim had visited the site previously) that the page should always be served over HTTPS - no HTTP request would ever have been sent, and the browser would just send a request to https://example.com. The attacker cannot MitM the TLS connection, so the attack is prevented.

(The fact that browsers cache 301 responses makes this a bit more complicated in practise. For more info on that, see bonsaiviking's great answer or this question. The short story is that the 301 being cached might help a bit, but not take you all the way that HSTS does.)

  • 15
    It would be worth mentioning that sslstrip helps exploit exactly these kind of attacks.
    – sandyp
    Jul 5, 2016 at 23:23
  • 6
    @l0b0 You are only preloaded if you (a) set the preload flag, and (b) apply for it. A minority of HSTS sites are preloaded, so for most sites you need to visit it.
    – Anders
    Jul 6, 2016 at 7:38
  • 6
    @ValmikyArquissandas I disagree. A majority of HSTS sites does not use preloading, and they get a significant advantage anyway. Unlike HSTS posts, a 301 is not guaranteed to be cached for any extended time, it only covers a specific page and not a full domain, and it is lost if the user purges the cache.
    – Anders
    Jul 6, 2016 at 13:15
  • 1
    @Anders: you are obviously correct, and my answer is wrong. I don't know how I forgot that 301 acts on a single page only, and not over the domain - I must've mixed them up. Jul 8, 2016 at 10:04
  • 1
    @DavidSpector You are wrong, as was pointed out to you in both your (incorrect) answer to this question and in your other question. Dec 27, 2019 at 21:01

HTTP Strict Transport Security (HSTS) is designed for security. HTTP 301 Moved Permanently is used for URL redirection.

The 301 redirect is an important part of deploying an HTTPS website. As part of the HTTP protocol, it is supported by more browsers than HSTS. It serves as the primary means for upgrading a plaintext connection to HTTPS, updating search indexes, and avoiding link rot.

In many cases, these two methods have the same weakness: the initial request when the user types "example.com" in their browser is sent plaintext. If that initial request is made on a hostile network with an active man-in-the-middle (MITM), the response can be intercepted and the connection will not be upgraded to a secure one.

However, there are many reasons why HSTS is important and a big security improvement over a standard 301 redirect:

  • HSTS covers the entire domain. A 301 redirect only covers a specific URI path. If a user is redirected for example.com/, then a later request to example.com/somepage will still use HTTP initially, and must be redirected again. A site using HSTS requires only one request to cover the entire site.
  • HSTS works even with an initial HTTPS connection. A 301 redirect only maps a plaintext URI to a HTTPS one, so visiting the HTTPS one directly confers no protection to subsequent visits.
  • HSTS uses a separate cache with a separate timeout. The 301 cache is often tied to the browser's request cache, which is designed for performance. If you don't visit a page for a while, it will probably be cleared out of the cache to favor more-frequently-visited sites. There may even be a max-age for this cache that is a few weeks or months. A common fix for "site does not work" is telling the user "clear your cache." All of these would re-expose the user to the MITM threat. HSTS timeouts are usually on the order of months to years, and the cache is usually separate, so it cannot be easily or accidentally cleared.
  • HSTS can be preloaded into a browser by the manufacturer. Google does this with their Chrome browser based on headers discovered during web crawling and submitted directly to their program. For preloaded sites, the browser will never need to visit via plaintext in the first place; it can always be assumed to be HTTPS-only.
  • 2
    A "separate cache" that still needs to be purged when the user request anonymity, so still a half backed solution
    – curiousguy
    Jun 20, 2018 at 22:38

First of all, some old browsers don't support HSTS, so you still need to redirect HTTP to HTTPS, set the secure flag on all cookies, etc. Now, with that said...

In addition to the fine reasons listed above, since defeating SSLStrip-type attacks is one of the main purposes of HSTS, there's another attack that HSTS protects against but simple redirects do not.

Let's say a site is being visited entirely on HTTPS. The user is really careful, and only ever requests this site over HTTPS. No redirect needed. There's no HSTS, but there's not any links to the site over unsecured HTTP either, so all traffic with the site is encrypted.

However, suppose the site has a security vulnerability where it reflects a specific cookie (if present) into the page without proper escaping (cookie-based XSS, rare but hardly unheard-of). The attacker can't actually read (much less modify) the HTTPS traffic, but they really want to access the user's session on that HTTPS site. So, they wait for the user to visit some other site over HTTP, and modify the response from that site to include an invisible request (maybe a script src) to http://securesite.com/ (your HTTPS-only site, but over HTTP instead). What happens next:

  • If the site has an active HSTS policy in the browser, then the browser automatically re-writes the request as https://securesite.com/ and the attacker can't read or modify any traffic.
  • If the attacker doesn't tamper but the site has no HSTS, then the request goes out, gets a 301 to https://securesite.com/, and the request goes out again via HTTPS.
    • However, any cookies for securesite.com but without the secure flag on them will be included with that initial unsecure request. The attacker can read them even just via passive eavesdropping at that point. That's bad (and this is a reason why sensitive cookies must always have the secure flag even if the site shouldn't ever be accessed over an insecure connection).
  • If all the cookies are secure, though, that makes this attack pointless. The attacker will have to tamper again. They can forge or modify the response to the insecure request. In this particular case, the attacker would add a Set-Cookie header to the response, putting a cookie in the user's browser that will be sent on future requests to securesite.com, over either HTTP or HTTPS.

With the hypothesized cookie-based XSS vector (or anything else where a cookie-planting attack can do harm), the attacker has successfully attacked a site that the user was very careful to only access over HTTPS, just because it wasn't using HSTS and had a vulnerability that would be impossible to exploit without an unsecured connection.

  • Regarding old browsers. It is controversial if a site does or doesn't need a 301. I guess that's rather ultimately users who are responsible to type https: prefix if they insist on using unsupported browser. It's a business decision if you want to sacrifice some security and comfort that user base.
    – kubanczyk
    Jul 6, 2016 at 11:40
  • 6
    Wait, how and where is this controversial? If you use HSTS, you absolutely need to include the 3xx redirect as well! You can't even send an HSTS header over HTTP (at least, no conforming client will respect it, with good reason), nor can you preload HSTS if you respond over HTTP with anything but a redirect. Anywhere that this entire question is even slightly relevant, the use of the redirect is mandatory.
    – CBHacking
    Jul 6, 2016 at 18:00
  • The redirect isn't really needed for new browsers, but recommended for simplicity and for browsers that do not support HSTS. All that's needed to enable HSTS is a single resource loaded over HTTPS that includes the header. It could be as simple as an absolute URL reference (e.g. <img src="https://example.com/img.jpg" />). Jul 8, 2016 at 10:57
  • @SilverlightFox: Doing that will still make the root page itself load over HTTP on that initial request, which may reveal some user content and also causes a bad user experience (possibly making the user think that the site is operating fully over HTTP). It will also make your site ineligible for the HSTS preload list (requirement #2 at hstspreload.appspot.com)
    – CBHacking
    Jul 8, 2016 at 20:11

The key thing to note is that the Same Origin Policy for cookies is more lax than the Same Origin Policy elsewhere. That is, there is not a single secure channel for cookies, they are the same origin:

Client ----Plain HTTP----> Server
Client ---------HTTPS----> Server

Of course the Secure Flag can be set so a cookie value can be set to only transfer over HTTPS.


Set-Cookie: foo=bar; secure

Client --> HTTP  (no cookies)      --> Server
Client --> HTTPS (Cookie: foo=bar) --> Server

However, there is no way for the server to know whether a cookie was set with the Secure Flag.

e.g. over plain HTTP

Set-Cookie: foo=bar

Client --> HTTPS (Cookie: foo=bar) --> Server

The server will be in this situation:


So although cookies set by the server over HTTPS are not sniffable, a MITM can inject their own values into a "secure" session. This is true even if you have no plain HTTP service:

Client ----Plain HTTP----> No service
Client ---------HTTPS----> Server

...because a MITM can still generate a plain HTTP request to your domain and inject the cookie:

Client ----Plain HTTP----> MITM --> No service
Client ---------HTTPS-------------> Server

This can lead to some attacks should your site have some vulnerabilities that might not otherwise be able to be exploited:

As well as the above, ssltrip style attacks can be carried out without HSTS. sslstrip relies to a degree on the user not noticing their is no HTTPS.

Also see this answer.


HSTS uses a sandboxed client side 307 redirect, so it does not even hit the server until it's in explicit https mode. A 301 redirect on the other hand is server side, takes resources, time to complete, etc. Also, a 301 stacks up your [chained] redirect count, which is generally attributed to SEO dilution.

So HSTS is generally the better choice due to its client side + sandboxed nature. But, there is a "danger" to it with a very long TTL on cache. When an SSL expires or if you want to go back http mode users will be locked out. This is because the cached HSTS TTL is/will only look for https, but browsers will nogo sites with an expired cert. So don't ever let it expire or switch modes without setting HSTS cache time to 0 in the weeks (or months) before the change :) You don't have to worry about this with 301 since it's not the browser making the decision to redirect or not -- people won't get locked out if you make the change server side.

  • 2
    Browsers cache 301 responses, so you might look out users with those if you disable HTTPS:
    – Anders
    Jul 6, 2016 at 16:51
  • It is true that HSTS itself is secure. But if the user is accessing with http, and the site is not preloaded, there is no way to discover the HSTS header without redirection from http to https. In other words, once an http request is made, MiTM is possible. The trick is to avoid making ANY http requests, unless the link in an old one, the website is for a household appliance, etc. One solution is to add a new feature to DNS zone records to say, "this domain supports https". Dec 27, 2019 at 19:44
  • @DavidSpector For the umpteenth time, "and the site is not preloaded" So preload then. Dec 27, 2019 at 21:31
  • @DavidSpector HSTS is a backup client-side enforcement mechanism. It's not a replacement for server-level mechanisms...it's an addition. If your server/app/site is set to enforce https mode always and everywhere, it will never serve a http request back to begin with. You can do this right at the nginx/apache level. A visitor could never get to a http page, an insecure session would never be generated, insecure cookies wouldn't be used, etc. Wouldn't matter when they see the HSTS header then, as one wouldn't be relying on it, per-say.
    – dhaupin
    Dec 31, 2019 at 20:52
  • @JosephSible-ReinstateMonica it helps to add that flag for sure, but the preload list in browsers is still used. So if you have the flag, but your domain isn't on that list, it won't preload. You can submit your domain here: hstspreload.org. I dunno if or how long it takes to get added :)
    – dhaupin
    Dec 31, 2019 at 20:56

Since HSTS still requires a redirection the first time each user visits your website (unless we are so sure of no errors that irreversible preloading via registration can be dared), this is a trick question. There essentially is no difference between using the HSTS header and using a redirection header.

The only good solution I can think of is adding a record type or flag to each DNS zone record to specify "this domain supports HTTPS". Then there is no need for HSTS or redirection. The browser already knows that https is supoorted (from its DNS lookup), so it can (unless overruled by the user) rewrite the user's http to https before it even sends the first request to the remote server.

  • This is incorrect. A 301 redirect only affects the specific URL that you hit it on, but HSTS affects the entire domain. And you're also making preloading sound much worse than it actually is. Dec 27, 2019 at 20:55
  • 1
    This is not a "trick question". You have not properly represented what happens in HSTS. Also, the question is from the server-side. You are proposing an entirely new protocol.
    – schroeder
    Dec 27, 2019 at 22:04
  • HTTPS Everywhere (eff.org/https-everywhere) does what you want client-side.
    – schroeder
    Dec 27, 2019 at 22:06

You must log in to answer this question.

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