What's the difference between using HSTS and doing a 301 redirect?

Learn why you should use HSTS even if you have a 301 redirect from all HTTP pages to HTTPS


Written by Abi Tyas Tunggal

TL;DR? HTTP Strict Transport Security (HSTS) is designed for security while HTTP 301 Moved Permanently is designed for URL redirection.

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.

The HTTP response status code 301 Moved Permanently is commonly used to upgrade plaintext connections to HTTPS and to permanently redirect duplicate or old content to new pages. As it's part of the HTTP protocol, it is supported by more browsers than HSTS.

301s on their own are not sufficient to prevent man-in-the-middle attacks. To understand why let's walk through an example scenario.

Imagine a user sends a request to http://example.com, a website that only uses 301s to redirect plaintext connections to HTTPS. The visitor could be sending this request because of an SSL stripping attack or simply because they entered example.com in the address bar. By default, browsers will connect via HTTP unless instructed otherwise.

If there is no man-in-the-middle, the user will get a 301 response back and be redirected to https://example.com. If there is a man-in-the-middle, the attacker could choose to not send the 301 and instead serve a modified copy of the site over HTTP. The one key thing to understand is the initial HTTP connection is unencrypted and an attacker could therefore modify the traffic. The other is that the SSL handshake that comes with establishing an HTTPS connection also validates that the server is exactly who they say they are - something not done during a plaintext HTTP-based connection.

In contrast, if HSTS was implemented (and the user had visited the site before) the requests would always be served over HTTPS as HSTS instructs the browsers to only use HTTPS. In other words, no HTTP requests would be sent and the browser would only request https://example.com.

It's important to note 301s and HSTS share a key weakness. The initial request, when a user first visits a website, is sent plaintext. If that initial request is made on a hostile network with an active man-in-the-middle attack, the response could be intercepted and the connection would not be upgraded to a secure one.

The good news is this risk can be mitigated if HSTS is preloaded. If a website is on the HSTS preload list these browsers will never need to visit via plaintext and will always use HTTPS. HSTS can be preloaded by most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge).

This also gives you an idea of why UpGuard has three different risks related to HSTS:

  • HTTP Strict Transport Security (HSTS) not enforced: You should now understand why this is a risk. HSTS is a big improvement over 301s even without including subdomains and preloading.

  • HSTS header does not contain includeSubDomains: This is a risk because without the includeSubDomains parameter HSTS will not be enforced on subdomains. This is also a requirement for inclusion on the HSTS preload list.

  • Domain was not found on the HSTS preload list: This ensures that a user who has not visited the domain before will only connect with HTTPS. Read our article on how to resolve the Domain was not found on the HSTS preload list risk.

In summary, using HSTS is an important security improvement over standard 301 redirects because:

  • HSTS covers the entire domain: A 301 redirect only covers a specific URI path. If a user is redirected from http://example.com to https://example.com and then requests http://example.com/page they will still use HTTP initially before being redirected to https://example.com/page. A site using HSTS requires a single HTTP request to be upgraded to HTTPS to cover the entire site.

  • HSTS works even with an initial HTTPS connection: A 301 redirect only maps a plaintext URI to an HTTPS one, so visiting the HTTPS one directly confers no protection for subsequent visits.

  • HSTS uses a separate cache: 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'll probably be cleared out of the cache to favor frequently visited websites. There may even be a max-age for this cache that is a few weeks or months. Whenever the user clears their cache, they are re-exposed to the man-in-the-middle threat. In contrast, HSTS timeouts are usually on the order of months or years and the cache is usually segregated so it can't easily or accidentally be cleared.

  • HSTS can be preloaded into a browser: This ensures that a user using a modern browser like Chrome, Firefox, Opera, Safari, IE11 or edge only connect with HTTPS regardless of whether they've visited the site before or not.

    See also