HSTS (HTTP Strict Transport Security) is a web security policy by which a site instructs browsers to connect to it only over HTTPS for a stated period. In Internet trust, it closes the gap that certificates and TLS alone leave open: the first insecure request that an attacker can intercept before a secure connection exists.
HSTS is defined in RFC 6797 and is delivered through the Strict-Transport-Security response header. A browser that has received a valid policy rewrites every insecure HTTP address for that host to its HTTPS form before sending anything, and it refuses to let the user bypass certificate errors on that host.
How HSTS enforces secure connections
HSTS works by trust on first use. The first time a browser reaches a site over a valid HTTPS connection, the server returns a header such as Strict-Transport-Security: max-age=31536000; includeSubDomains. The browser stores the host name and the expiry time in its HSTS cache.
From then on, the browser applies two rules to that host. First, it performs an internal redirect from HTTP to HTTPS without touching the network, so no plaintext request is ever sent. Second, any certificate problem, such as an expired, self-signed or mismatched certificate, becomes a hard failure with no click-through option.
Browsers ignore the header when it arrives over plain HTTP, because an attacker could otherwise inject or remove it. Each new valid response refreshes the stored expiry, so a policy on an active site effectively never lapses.
HSTS directives and recommended values
The header has only three directives, but their values decide how strong and how reversible the policy is. The table summarizes them.
| Directive | Typical value | Effect |
|---|---|---|
| max-age | 300 seconds during testing, 31536000 or 63072000 in production | How long the browser remembers the policy |
| includeSubDomains | Present or absent | Extends the policy to every subdomain |
| preload | Present or absent | Signals consent to inclusion in browser preload lists |
| max-age=0 | Used only to withdraw | Deletes the stored policy at the next secure visit |
A max-age of one year (31536000 seconds) is the common production value, and two years is frequently recommended for sites that are confident in their HTTPS coverage. Short values reduce protection because returning visitors may arrive after the policy has expired.
The header must be sent on HTTPS responses only, and it is good practice to send it on every response, not just the home page, so that any entry point refreshes the policy. The policy is bound to the exact host name that sent it: a header from www.example.com protects neither example.com nor shop.example.com unless the apex domain sends its own header with includeSubDomains. For that reason, operators usually make the bare domain redirect to HTTPS on the same host first, deliver the header there, and only then redirect to the preferred host name.
The HSTS preload list
The preload list removes the first-visit weakness by shipping known HSTS hosts inside the browser itself. Major browsers share a list that originates in the Chromium project, so a preloaded domain is protected even on the very first connection.
To qualify, a domain must serve a valid certificate, redirect HTTP to HTTPS on the same host, serve every subdomain over HTTPS, and send a header with max-age of at least one year, includeSubDomains and preload. The following table compares dynamic and preloaded HSTS.
| Aspect | Dynamic HSTS | Preloaded HSTS |
|---|---|---|
| First visit protected | No | Yes |
| Scope | Host and optionally subdomains | Whole registered domain and all subdomains |
| Time to take effect | Immediately after first secure visit | Weeks to months, through browser releases |
| Time to remove | One visit with max-age=0 | Months, and old browser versions keep it |
| Risk of lockout | Limited to cached clients | Affects every user of supporting browsers |
Some top-level domains are preloaded as a whole, which means every domain registered under them must use HTTPS. Preloading is therefore close to a one-way commitment and suits domains that are certain never to need plain HTTP on any subdomain.
HSTS compared with related trust mechanisms
HSTS does not authenticate a server by itself; it forces the browser to use the existing PKI. It complements certificate authorities, X.509 certificates and revocation checking, as the table below shows.
| Mechanism | Problem it addresses | Relation to HSTS |
|---|---|---|
| HTTP to HTTPS redirect | Users typing plain addresses | Leaves the first request exposed; HSTS removes it |
| Certificate authority and X.509 | Proving server identity | HSTS makes validation failures non-bypassable |
| OCSP and revocation | Withdrawn certificates | Independent; HSTS does not check revocation |
| Certificate Transparency | Misissued certificates | Independent public logging of issuance |
| HPKP (key pinning) | Rogue but valid certificates | Deprecated after lockout incidents; not a substitute |
The attack HSTS targets most directly is SSL stripping, in which an attacker on the network path answers the initial HTTP request and keeps the victim on an unencrypted connection while proxying to the real HTTPS site.
Deployment risks and common mistakes
The strength of HSTS is also its main operational risk: a mistake cannot be undone quickly for users who already cached the policy. A staged rollout limits the damage.
- Start with a short max-age, such as five minutes, then raise it to a week, a month and a year once all hosts work over HTTPS.
- Audit subdomains before includeSubDomains, because internal tools, printers or legacy hosts without valid certificates become unreachable.
- Do not send the header from shared hosting or development environments where certificate errors are expected.
- Renew certificates automatically, since an expired certificate on an HSTS host produces an error that users cannot bypass.
- Remember that HSTS covers only browsers and other clients that implement it; scripts and many API clients ignore it.
The short version
HSTS is a site telling your browser: always use the locked door. After the first secure visit, the browser remembers this and never tries the unlocked door again, even if someone types the old address.
This matters because attackers on public networks like to catch that very first unlocked step. HSTS removes it. It also stops people from clicking past a security warning on that site, so a fake certificate cannot be waved through.
Where it makes a difference
A bank serves its online banking at a dedicated subdomain and already redirects HTTP to HTTPS. A security review notes that customers on hotel and airport Wi-Fi often type the bare domain, so the first request still goes out in plain HTTP and could be stripped.
The team inventories every subdomain, fixes two legacy hosts without valid certificates, and rolls out Strict-Transport-Security with max-age=300, then one week, then two years with includeSubDomains and preload. After the domain appears in the preload list, browsers connect over HTTPS from the first keystroke, and a later penetration test confirms that SSL stripping no longer works against customers using current browsers.