"We redirect all HTTP traffic to HTTPS, so we are covered." It is one of the most common security claims, and it is half right. A redirect and an HSTS policy both aim to keep users on HTTPS, but they operate at different moments and defend against different threats. Understanding the difference is the difference between closing the door and merely putting up a sign that asks people to close it.
What a plain redirect does
A classic setup listens on port 80 and answers every HTTP request with a 301 or 308 pointing at the https:// equivalent. The browser follows it, the address bar goes green, and every subsequent request is encrypted. For an honest network, that is a clean upgrade.
The problem is the very first request. When a user types example.com, follows an old http:// link, or clicks a bookmark from years ago, the browser's opening move is a plaintext HTTP request over the network. Your redirect is the response to that request — which means the insecure request has already left the machine and travelled across whatever WiFi, hotel network or hostile router sits between the user and you before your server ever gets to say "please use HTTPS".
Why that first request is dangerous
An attacker positioned on that path does not have to let your redirect through. This is the classic SSL-stripping attack: the attacker intercepts the plaintext HTTP request, talks to your site over HTTPS on the victim's behalf, and serves the victim a plain HTTP version of the page — no redirect, no lock icon, credentials and cookies flowing in the clear. The redirect you configured is simply discarded by the machine in the middle. Because the browser had no prior instruction to insist on HTTPS, it has no reason to be suspicious that the secure version never arrived.
A redirect, in other words, is advice delivered after the risky moment has already happened. It cannot protect the one request that occurs before the advice is heard.
It is worth noting that not all redirects are even equal here. A server-level 301 or 308 at least happens at the HTTP layer with no page rendered. A redirect implemented in application code, an HTML <meta> refresh, or a JavaScript location assignment is worse still: the browser has to receive and process an actual HTTP response body before the redirect fires, giving an on-path attacker not just a request to strip but a whole page to tamper with. However you implement it, though, the fundamental limitation is the same — the first request has already gone out in the clear.
What HSTS does instead
HSTS moves the decision to before the request leaves the browser. Once a browser has recorded your Strict-Transport-Security policy, it no longer emits a plaintext request to be intercepted. Typing example.com, following an http:// link — the browser rewrites the scheme to https:// internally and the first packet on the wire is already a TLS handshake. There is no plaintext request for an attacker to strip, and a downgrade attempt surfaces as a hard, unbypassable error rather than a silent success.
That is the essential distinction: a redirect fixes the request after it has been sent; HSTS prevents the insecure request from being sent at all.
Why you need both, not either
HSTS has a bootstrap problem: a browser only enforces the policy after it has seen the header, and — by specification — a browser ignores an HSTS header delivered over plain HTTP. The header only counts when it arrives on an HTTPS response. So how does a browser that started on HTTP ever receive it? Through the redirect. The redirect is what carries a first-time, HTTP-arriving visitor onto HTTPS, where your server can finally deliver the Strict-Transport-Security header that arms the policy for next time.
The two mechanisms are therefore complementary, not alternatives:
- The redirect gets HTTP visitors onto HTTPS so the header can be delivered — and it is a hard requirement for the preload list, which insists the apex redirect HTTP to HTTPS.
- HSTS then ensures that from the second visit onward, no plaintext request is ever made in the first place.
The practical configuration is simple: keep the port 80 listener redirecting everything to HTTPS, and add the Strict-Transport-Security header to your HTTPS responses — for example Strict-Transport-Security: max-age=31536000; includeSubDomains. One without the other leaves a gap. If you want to verify a redirect chain actually lands on HTTPS cleanly, Redirects Studio traces it hop by hop; to confirm the HTTPS endpoint's certificate and handshake are healthy, use TLS Studio and SSL Studio.
The gap that even both leave — and how preload closes it
Redirect plus HSTS still has one blind spot: a brand-new visitor whose browser has never seen your header. Their genuinely-first request can still go out over HTTP, and only your redirect — interceptable, as we saw — stands in the way. This is the first-visit gap.
The preload list closes it. By submitting your domain to hstspreload.org — which requires max-age of at least a year, includeSubDomains, the preload directive, and the HTTP→HTTPS redirect on the apex — you get your domain shipped inside the browser itself. Now HTTPS is enforced on the very first visit, before any request has been made, for users who have never touched your site. The redirect handles the transition, HSTS enforces it thereafter, and preload extends that enforcement back to the one request neither of the other two could protect.