HSTS and HSTS preload explained: downgrade protection, and its lock-in risk
HTTP Strict Transport Security (HSTS), defined in RFC 6797, is a response header that tells a browser to never load a site over plain HTTP again for a set period of time, closing off downgrade and cookie-hijacking attacks that rely on intercepting that first unencrypted request; HSTS preload extends the same protection to a visitor's very first connection by baking the policy directly into the browser itself, at the cost of a removal process that is deliberately slow.
By AdminKit team, Netbase JSC · Updated October 24, 2026
The problem: a brief, repeatable window to downgrade HTTPS
Even a site that serves everything over HTTPS is vulnerable at one specific moment: the instant a user’s browser tries to connect before it knows the site requires encryption — a typed address without https://, an old HTTP link, or a bookmark saved years ago. An attacker positioned on that network path can intercept the plain HTTP request and either keep the session downgraded or read and inject cookies before any redirect to HTTPS completes. RFC 6797 defines HSTS to close this window for every connection after the first: once a browser has received a valid Strict-Transport-Security header from a site, it rewrites every future request to that domain to HTTPS internally, before the request ever leaves the device, for as long as the header’s max-age specifies.
What the header actually buys you, and what it doesn’t
Strict-Transport-Security: max-age=63072000; includeSubDomains tells the browser to enforce HTTPS-only for two years, across every subdomain. This directly stops the two attacks described above, but only from the second connection onward — the header has to have been seen once already to take effect, which is precisely the gap preload addresses. This is a meaningfully different guarantee from a CA-issued certificate alone: a valid certificate makes an HTTPS connection trustworthy once it happens, while HSTS makes sure the HTTPS connection happens at all, for every visit after the first.
HSTS preload: solving the bootstrap problem by baking the policy into the browser
Rather than depending on a prior visit, a site can request inclusion in Chrome’s HSTS preload list, a list of domains hardcoded directly into Chromium’s source code and shipped with the browser itself; Firefox, Safari and other major browsers maintain preload lists derived from Chrome’s, per hstspreload.org’s own documentation. A domain on the list is HTTPS-only for every user, from their very first connection, with no bootstrap request required at all. The submission requirements are strict for good reason: a valid certificate, an HTTP-to-HTTPS redirect, and — critically — HTTPS support on every subdomain, including internal or non-public ones, since includeSubDomains is mandatory for preload inclusion.
The lock-in risk, and why it’s deliberate
hstspreload.org is explicit that new preload entries are hardcoded into Chrome’s source and can take several months to reach the stable release channel, and that the same is true of removal — a site preloaded before every subdomain was actually ready for HTTPS can end up with parts of its infrastructure unreachable in any preload-respecting browser for months, with no quick way to back out. This is why hstspreload.org’s own guidance tells tools and setup wizards to make preloading opt-in rather than a default, and states plainly that while the HSTS header itself is recommended, preloading specifically is not recommended for every site — only for domains certain that HTTPS will remain universal across every current and future subdomain.
How to check and decide
Confirm your HSTS header is actually present and correctly scoped before even considering preload — inspect it with any browser’s network devtools or, once AdminKit’s SSL/TLS check ships, with a direct header check. If every subdomain you control and plan to ever add supports HTTPS unconditionally, preload closes a real first-connection gap; if you’re not certain of that yet, the HSTS header alone — without the preload directive — already provides the main protection without the multi-month lock-in.
Related checks
HSTS, Certificate Transparency and CAA records each protect a different stage of the same trust chain: see Certificate Transparency logs explained for how mis-issued certificates become visible after the fact, what CAA records do for limiting who can issue a certificate for your domain in the first place, and reading a TLS/SSL certificate check result for what to check once a connection is actually established.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
What does the HSTS header actually do?
A site sends `Strict-Transport-Security: max-age=<seconds>` (optionally with `includeSubDomains`) over an HTTPS response, and RFC 6797 specifies that a compliant browser must then refuse to load that domain over plain HTTP for the stated duration — any `http://` link or typed address gets rewritten to `https://` internally before a request is even sent. This closes two concrete attacks: an on-path attacker rewriting a redirect from HTTP to HTTPS to keep the connection downgraded, and an attacker reading or injecting cookies during that same unencrypted first hop.
If HSTS only applies after the first visit, what protects the very first connection?
Nothing, by design — RFC 6797's mechanism can only take effect once a browser has already seen the header from a prior HTTPS visit, which leaves a real gap: if a user's first-ever connection to a domain happens to be over HTTP (an old bookmark, a typed address without 'https://', a link from an old search result), an on-path attacker gets one shot at intercepting that first request before HSTS has ever been recorded. This is often called the 'trust on first use' or 'bootstrap' problem, and it's the exact gap HSTS preload is built to close.
How does HSTS preload close that gap?
Instead of waiting for a browser to see the header once, a site can submit its domain to Chrome's HSTS preload list, maintained at hstspreload.org, which ships as a hardcoded list baked directly into the browser's source code; Firefox, Safari and other major browsers maintain their own lists based on Chrome's. Once a domain is on the list, a browser enforces HTTPS-only from the very first connection it ever makes to that domain, with no prior visit required — closing the bootstrap gap entirely, at the cost of every subdomain needing to support HTTPS, including internal ones that were never meant to be public.
Why is HSTS preload described as having a 'lock-in' risk?
Because reversing it is slow by design. hstspreload.org documents that new entries are hardcoded into Chrome's source and can take several months to reach the stable browser release, and that removal is similarly slow — a site that preloaded before confirming every subdomain actually supports HTTPS can end up with subdomains unreachable in any preload-respecting browser for months, with no fast way to undo it. hstspreload.org's own guidance is explicit that tools and guides should make preloading opt-in, not a default, specifically because of how often site operators have been burned by this.
Should every site submit itself to the preload list?
Not automatically. hstspreload.org's own position is that the HSTS header itself is recommended, but preloading specifically is not recommended for every site — it's intended for sites that are certain every current and future subdomain will support HTTPS indefinitely. A site still gets strong protection from the HSTS header alone after a user's first HTTPS visit; preload only adds value for the narrow bootstrap-connection scenario, and that narrow benefit should be weighed against months of inflexibility if a subdomain ever needs to run HTTP again.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.