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, 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 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 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 a 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

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 to and then requests they will still use HTTP initially before being redirected to 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.

If you want to learn more about HSTS or man-in-the-middle attacks, please read our blog posts:

Did this answer your question?