HSTS and the preload list: how to enable it without locking yourself out
Redirecting HTTP to HTTPS closes most of the gap, but not all of it. The first request still leaves the browser in plain text, and an attacker positioned on the network can intercept it before your redirect ever arrives. HTTP Strict Transport Security removes that first request. Once a browser has seen the header, it rewrites every future request to your domain as HTTPS internally, before anything touches the network.
It is one of the highest value headers you can set. It is also the one that most deserves a careful rollout, because the strongest version of it is close to permanent.
The header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Three parts, and each carries real weight.
max-age is how long, in seconds, the browser should remember the rule. The value above is one year. The clock resets every time the browser sees the header, so an active site keeps refreshing it.
includeSubDomains extends the rule to every subdomain. This is the directive that causes outages, because it applies to subdomains you may have forgotten about: an old legacy.example.com on plain HTTP, a status page, a vendor hosted mail.example.com. Once the browser has the rule, those become unreachable rather than degraded. There is no click through warning to bypass it.
preload is a signal that you want the domain baked into browsers themselves.
What preloading changes
HSTS as described so far has a gap: the browser has to visit you once over HTTPS to learn the rule. A brand new visitor, or one whose cache has expired, still makes that one unprotected request. This is trust on first use, and preloading is how you close it.
The preload list is a set of domains compiled into the browser binary. Chrome maintains it and Firefox, Safari, Edge and Opera consume it. If your domain is on that list, browsers refuse plain HTTP to it from the very first request, before they have ever contacted you.
To be accepted at hstspreload.org a site must:
- serve a valid certificate,
- redirect HTTP to HTTPS on the same host,
- serve the header on the base domain over HTTPS,
- use
max-ageof at least 31536000 (one year), - include
includeSubDomains, - include the
preloadtoken.
The part people underestimate
Removal is slow and partly outside your control.
Requesting removal from the preload list starts a process that takes months to reach a browser release, and only reaches users when they update. Meanwhile every browser that already has the entry keeps enforcing it. There is no way to push a correction, no cache you can purge, and no override for your visitors.
So treat preloading as a commitment that every hostname under your domain will speak HTTPS indefinitely. If there is any chance you will need to expose something on plain HTTP under that domain, or hand a subdomain to a third party that cannot do TLS, do not preload.
A rollout order that does not break things
The mistake is copying the full header from a hardening guide and deploying it. Ramp instead, and stop at whichever step matches your actual risk tolerance.
1. Inventory every subdomain first. You cannot reason about includeSubDomains without knowing what it covers. Enumerate from DNS and from certificate transparency logs, since CT logs reveal hostnames that never appear in your zone file exports. The CT log lookup lists certificates issued for your domain, which is the most reliable way to find hosts you have forgotten.
2. Confirm every one of them serves HTTPS correctly. Not just the main site. Check the chain and expiry on each host with the bulk SSL checker so a single expired certificate on a neglected subdomain does not become an outage the moment the policy applies.
3. Start with a short max-age and no subdomains.
Strict-Transport-Security: max-age=300
Five minutes. If something breaks, it self corrects almost immediately. Verify the header is arriving with the HTTP header inspector.
4. Raise gradually. Move to a day, then a week, then a month, pausing at each step long enough to be confident. Nothing forces you to rush, and each increase is only as risky as the time it takes to expire.
5. Add includeSubDomains at a short max-age. Drop the max-age back down when you first add it, then ramp again. This is the directive most likely to surface a forgotten host, and you want that discovery to expire in minutes rather than a year.
6. Only then consider preload. By this point you have run the full policy for months without incident, which is the only real evidence that preloading is safe for you.
Common mistakes
Sending the header over plain HTTP. Browsers ignore HSTS on a non secure response, by design, since an attacker who can modify HTTP could otherwise use it to deny service. Set it on HTTPS responses only.
Setting it on the redirect instead of the destination. The header needs to be on the HTTPS response. A header attached to the 301 from HTTP does nothing.
Leaving preload in the header without submitting. The token alone does not enrol you, but it does tell scanners you intended to. Either submit the domain or remove the token, so the header reflects reality.
Assuming it replaces the redirect. It does not. Keep redirecting HTTP to HTTPS, because HSTS only helps browsers that have already learned the rule or shipped with it.
Applying it to an apex that serves an unrelated subdomain estate. includeSubDomains on example.com covers every host under it, including ones owned by other teams. Confirm before you assert it.
Verifying it works
Load the site over HTTPS and read the response headers back. The HTTP header inspector shows the full set along with the redirect chain, so you can confirm both that HTTP redirects to HTTPS and that the HTTPS response carries the policy you expect.
In the browser, Chrome exposes the live state at chrome://net-internals/#hsts, where you can query a domain and, usefully during testing, delete the cached entry so you can start again from a clean state.
Related reading: HTTP versus HTTPS covers what TLS protects in the first place, and content security policy is the other header worth the same careful rollout.