The Gap HSTS Fills
Most people never type https://. They type example.com, and the browser's first attempt is often plain HTTP on port 80, which the server then redirects to HTTPS. That redirect works, but it leaves a brief insecure moment: the very first request travels unencrypted before the upgrade happens. An attacker positioned on the network can pounce on exactly that moment.
HSTS removes the insecure attempt entirely. It is a policy a site declares once, after which the browser stops trying HTTP for that site at all — it rewrites every http:// request to https:// internally, before anything leaves the device, and refuses to connect any other way.
The Strict-Transport-Security Header
HSTS is delivered as a single HTTP response header sent over HTTPS:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Each part has a specific job:
max-age— how long, in seconds, the browser must enforce HTTPS for this site. The example above is one year. The browser remembers this and re-applies it on every future visit until it expires.includeSubDomains— extends the policy to every subdomain, somail.example.comandshop.example.comare covered too, not just the bare domain.preload— signals the operator's intent to have the domain added to browsers' built-in HSTS lists (more on this below).
Once a browser has seen this header on a secure connection, the policy is locked in for the stated duration. Type http://example.com during that window and the browser silently upgrades it to HTTPS without ever touching the network insecurely.
The Attack It Stops: SSL Stripping
The threat HSTS targets is SSL stripping, a classic man-in-the-middle technique. An attacker sitting between the user and the site — on open Wi-Fi, say — intercepts that initial plain-HTTP request and quietly keeps the user's connection on HTTP while talking to the real site over HTTPS. The victim sees an ordinary-looking page with no lock icon they happened to check, while the attacker reads and even alters everything: passwords, session cookies, form data.
HSTS defeats this because there is no longer any HTTP connection to strip. The browser refuses plain HTTP for the site outright, so the attacker has nothing to intercept and no downgrade to perform. The encryption that TLS provides is only useful if it is actually used — HSTS is what guarantees it is.
The First-Visit Problem and Preloading
There is one hole in the basic scheme. Because the policy arrives in an HTTPS response, the browser only learns it after connecting securely at least once. A user's very first visit to a site — before any policy is stored — could still be attacked. Clearing browser data resets this too.
The HSTS preload list closes that gap. It is a list of domains hardcoded directly into browsers (and shared across major ones) that are treated as HSTS-enforced from the very first connection, before the browser has ever contacted them. A site operator submits the domain to be included, having served the header with preload set. From then on, participating browsers never attempt HTTP for that domain — not even once — so the first-visit window disappears.
| Header-based HSTS | Preloaded HSTS | |
|---|---|---|
| How the browser learns the policy | From a header on a prior HTTPS visit | Built into the browser itself |
| Protects the first-ever visit? | No | Yes |
| Survives clearing browser data? | No — must be re-learned | Yes — it ships with the browser |
Practical Considerations
HSTS is powerful precisely because it is sticky, which also makes it unforgiving. While a policy is active, a browser will not let a user click through a certificate warning for that site — there is no "proceed anyway" escape hatch — so a misconfigured or expired certificate makes the site genuinely unreachable until fixed. The same applies to subdomains once includeSubDomains is set: every one of them must serve valid HTTPS. And because preload-list removal is slow, operators are advised to roll out with a short max-age first and only commit to preloading once HTTPS is solid everywhere. Used carefully, HSTS turns "HTTPS is available" into "HTTPS is guaranteed" — which is the whole point. It pairs naturally with serving the right redirect status codes for any legacy HTTP links.
Frequently Asked Questions
What is HSTS?
HTTP Strict Transport Security — a policy a site sends in a response header telling browsers to only ever connect over HTTPS. After seeing it, the browser upgrades any http link to https and refuses insecure connections.
What does the Strict-Transport-Security header do?
It enforces HTTPS for a set period. max-age sets that period in seconds, includeSubDomains extends it to all subdomains, and preload signals eligibility for browsers' built-in HSTS lists.
What attack does HSTS prevent?
SSL stripping — a man-in-the-middle downgrade from HTTPS to HTTP. With HSTS the browser refuses plain HTTP, so there is no insecure connection to intercept or downgrade.
What is the HSTS preload list?
A set of domains hardcoded into browsers as HSTS-enforced from the very first visit, closing the gap that normal header-based HSTS leaves before a site's policy is first learned.
What is the first-visit problem?
HSTS arrives over HTTPS, so a browser only learns the policy after one secure connection; a very first visit could still be attacked. Preloading solves it by shipping the policy inside the browser.