HSTS and HSTS Preload: Enforcing HTTPS Without Locking Users Out

An HTTP to HTTPS redirect does not stop an on-path attacker from keeping a user on plaintext HTTP, and HTTP Strict Transport Security (HSTS) exists to close that gap, but a careless HSTS or preload rollout can lock users out of every subdomain you own. This guide goes deeper than the header summary in our Security Headers Guide: how browsers store and apply an HSTS policy, what the preload list really is and who maintains it, why the list's own maintainers now say preloading is not recommended for most sites, and how to ramp up, measure and roll back safely. It also covers the HTTPS DNS record, which gives browsers an HSTS-like signal before the first visit. It is written for web platform engineers, application security teams and anyone who owns a domain portfolio with internal or legacy subdomains.

Key takeaways

• HSTS is a browser memory, not a server setting. Once a browser has seen the header over HTTPS it rewrites every http:// URL for that host to https:// and refuses certificate click-through until max-age expires.
• includeSubDomains is where the risk and the value both live. It protects cookies set on the parent domain from insecure subdomains, and it breaks any subdomain, internal or public, that cannot serve a valid certificate.
• Preloading is a one-way door with a slow exit. The list is compiled into Chrome and copied by Firefox, Safari and Edge; removal takes months to reach users and other browsers give no guarantee.
• The list's maintainers say HSTS is recommended but preloading is not. Modern browsers already try HTTPS first, so preloading only adds value against an active attacker who can make that upgrade fail. OWASP ASVS 5.0 still asks for it at Level 3, so decide per domain.
• Certificate automation is a precondition. With HSTS active an expired certificate becomes a hard outage with no user bypass, so ACME renewal and expiry monitoring come before long max-age values.

How HSTS works in the browser

HSTS is defined in RFC 6797 (November 2012). A host opts in by sending the Strict-Transport-Security response header over HTTPS. The browser then adds the host to its persistent list of HSTS hosts and applies the policy to future requests, not to the response that carried it. The behaviour that matters in practice:

• Header over HTTP is ignored: browsers discard the header when it arrives over plaintext, so an attacker cannot inject a bogus policy or expire a real one. The HTTP to HTTPS redirect itself should not carry the header.
• URL rewriting: before loading an http:// URL the browser checks its HSTS list. On a match it changes the scheme to https and port 80 to 443; any other explicit port stays the same and is used with TLS. RFC 6797 Section 8.3 describes this rewrite.
• No user recourse: for an HSTS host, a certificate error ends the connection with no "proceed anyway" option (RFC 6797 Sections 8.4 and 12.1). This is what defeats the rogue Wi-Fi access point with a self-signed certificate.
• Host names only: an IP address cannot be an HSTS host, and the policy applies to all ports on the named host.
• Sliding expiry: each response with the header resets expiry to now plus max-age, so a fixed max-age on every response never lapses for active users. If a later response omits the header, the cached policy stays until it expires.
• Turning it off: max-age=0 deletes the policy, but only for browsers that make a new HTTPS request and see it. You cannot disable HSTS over HTTP, by design.

The weakness HSTS cannot fix on its own is the first visit. A browser that has never seen the header can still be kept on HTTP by an attacker who rewrites the redirect, which is the classic SSL stripping attack mapped in ATT&CK as Adversary-in-the-Middle (T1557). Preload lists and the HTTPS DNS record exist to close that bootstrap gap. See the Man-in-the-Middle Attacks Guide.

Directives and header values in practice

• max-age: seconds the browser should remember the policy. The hstspreload checker warns when the value exceeds ten years, which is unusual and gives you nothing extra.
• includeSubDomains: applies the policy to every subdomain and nested subdomain of the host that sent it. A policy on secure.example.com covers login.secure.example.com but not example.com or other.example.com.
• preload: not part of RFC 6797. It signals consent to be added to the list; you still have to submit the domain. OWASP warns that sending it can have permanent consequences.

Two placement details catch teams out. First, browsers store each host's policy separately, so if users only ever reach www.example.com they never see the apex header; send HSTS on www and on every user-facing host, and make sure the apex is visited (for example through a first-party resource) if you rely on its includeSubDomains. Second, set the header at the outermost HTTPS terminator you control, which is often the CDN or load balancer, and confirm the application behind it does not add a second, conflicting header.

Why includeSubDomains matters for cookies and sessions

A cookie set with Domain=example.com is sent to and can be overwritten from any subdomain. OWASP's HSTS cheat sheet notes that omitting includeSubDomains leaves a broad range of cookie attacks open, because an attacker on the network can impersonate an unused or HTTP-only subdomain such as http://nonexistent.example.com and inject or read cookies there. The Secure attribute stops a cookie being sent over HTTP, but it does not stop an insecure subdomain from setting a cookie that shadows yours.

• Use host-only session cookies: the __Host- prefix, defined in the RFC 6265bis cookie draft, requires Secure, Path=/ and no Domain attribute, which locks the cookie to one host. ASVS 5.0 V3.3.1 asks for Secure plus either __Host- or __Secure-. See the Cookie Security Guide.
• Pair HSTS with includeSubDomains on the apex: this is the only way to stop the browser speaking HTTP to subdomains that do not exist yet or that an attacker invents.
• Watch for dangling records: a forgotten CNAME that someone else can claim gets a valid certificate easily, and HSTS will not save you from a subdomain an attacker now legitimately controls. See the Subdomain Takeover and Dangling DNS Guide.

The preload list: what it is and who runs it

Because a browser cannot know a site's policy before the first visit, Chrome maintains a list of domains with a strong HSTS policy that are HTTPS only, compiled into the browser. hstspreload.org states that Firefox, Safari, IE 11 and Edge have preload lists based on the Chrome list. Requests to listed domains are upgraded to HTTPS and fail to connect if HTTPS is unavailable. MDN adds that although the service is hosted by Google and used by all major browsers, it is not part of the HSTS specification.

Submission requirements

Requirements are continuous. hstspreload.org says removing the preload directive makes a domain immediately eligible for the removal form and that domains may be removed automatically for failing to keep up the requirements. Domains preloaded between Chrome 50 and Chrome 63 were held to an 18 week (10886400 second) minimum; anything submitted on or after 11 October 2017 needs one year. Chromium's list file tags these as bulk-18-weeks and bulk-1-year entries, and also records whole top-level domains preloaded at the registry's request (for example app, dev and bank), which is why every site on those TLDs needs HTTPS from day one.

Time to effect and removal

• Inclusion: new entries are hard-coded into Chrome's source and can take several months to reach the stable channel; other browsers then import on their own schedule. You can check Chrome's view at chrome://net-internals/#hsts.
• Removal: remove the preload directive, keep serving HTTPS, and use the removal form. The checker rejects a removal request while the header still contains preload. hstspreload.org warns that removal takes months to reach Chrome users and that it cannot make guarantees about other browsers.
• Opt-in only: the maintainers ask anyone shipping HTTPS configuration defaults not to include preload, because operators regularly find themselves listed without realising some subdomains cannot do HTTPS.

Deciding: HSTS only, HSTS with subdomains, or preload

hstspreload.org now says plainly that while HSTS is recommended, preloading is not, because Chrome and Safari automatically try HTTPS for navigations and preloading only helps when an active attacker makes that upgrade fail. OWASP ASVS 5.0 V3.7.4 asks for the top-level domain to be on the public preload list, but only at Level 3. Treat preload as a deliberate control for high-value domains rather than a hygiene default.

• Small organisations: one marketing site plus a few SaaS-hosted subdomains. includeSubDomains is usually achievable quickly because every SaaS provider serves HTTPS; check vendor-hosted names such as status pages and mail tracking hosts first.
• Large organisations: the apex domain often anchors intranet names, printers, appliances and VPN portals in split-horizon DNS. Here includeSubDomains on the apex is a programme, not a header change. Move internal names to a separate internal domain before applying it, and keep preload for brand domains that are already clean.
• Shared or customer-controlled subdomains: if customers point their own content at your subdomains, you are committing them to HTTPS too. Agree that contractually before enabling includeSubDomains.

Beyond the header: HTTPS records and upgrade-insecure-requests

• HTTPS DNS record: the SVCB and HTTPS resource record specification (RFC 9460) says that the presence of an HTTPS record for an origin indicates that clients should use the https scheme, and clients that support it look it up before making an http request and treat a match like a 307 redirect. Because DNS is often unauthenticated, the specification says clients must not trust this signal more than a cleartext redirect, so it improves first-visit behaviour without replacing HSTS. It also allows clients to remove certificate click-through for that origin, so you must not rely on users bypassing errors. Protect the zone with DNSSEC where you can. See the DNS Security Guide.
• CSP upgrade-insecure-requests: rewrites a page's own insecure subresource URLs to HTTPS, useful for large legacy sites with hard-coded http:// links. MDN is explicit that it does not upgrade top-level navigations from third-party links and does not replace HSTS. See the Content Security Policy Guide.
• Browser HTTPS-first modes: automatic upgrades in modern browsers reduce exposure but fall back to HTTP when HTTPS fails, which is precisely the case an attacker creates. HSTS removes the fallback.

Implementation: a staged rollout

1. Inventory every name under the domain. Export public and internal DNS zones, search Certificate Transparency logs for issued names, and list SaaS-hosted subdomains. Mark each as HTTPS-ready, fixable or must-move. See the Certificate Transparency Guide.
2. Make certificates boring. Automate issuance and renewal with ACME, alert at 30, 14 and 7 days before expiry, and remove manual renewals on any host that will fall under the policy. See the ACME and Automated Certificate Management Guide.
3. Fix redirects. Every port 80 listener sends a 301 to HTTPS on the same host. The apex goes to HTTPS apex first, then to www if needed.
4. Deploy the header on HTTPS only, at the edge. Start at max-age=300; includeSubDomains for an internal or beta cohort if your platform can target one, as hstspreload.org suggests.
5. Ramp in stages and wait out each one. 300 seconds, then one week, then one month, watching error rates, support tickets and traffic. Wait the full max-age of each stage before moving on, so cached policies have had time to expose problems.
6. Move to one year or two. Keep includeSubDomains. This meets ASVS 5.0 V3.4.1 at Level 2 and above.
7. Decide on preload separately. Record the business owner's sign-off, the subdomain inventory date and the plan for future subdomains, then add preload and submit at hstspreload.org.
8. Rollback plan. Before preload: drop to max-age=0 on HTTPS and keep the HTTPS endpoint alive so browsers can receive it; only browsers that revisit will clear. After preload: fix forward by bringing the broken subdomain onto HTTPS, because list removal will not help users for months.

Detection, testing and measurement

• Header presence and value: scan all public hostnames daily for a Strict-Transport-Security header with the expected max-age and includeSubDomains, including on redirect responses. Alert on missing, duplicated or shortened values.
• Edge logs: track requests that still arrive on port 80 by host. A falling count on HSTS hosts shows the policy is working; a steady count often reveals non-browser clients or links in emails that need fixing at source.
• Certificate health: monitor days to expiry and chain validity on every host covered by includeSubDomains. Under HSTS these are availability metrics, not just security metrics.
• New subdomain gate: make DNS change requests for the domain fail review unless the name has a certificate plan, so the inventory you built does not decay.
• Preload status: check the domain's status on hstspreload.org after each header change and confirm the preload directive has not been dropped by a CDN or configuration change.

Common failure patterns

• Preload by default: a hosting panel or configuration snippet ships preload, the domain lands on the list, and an HTTP-only intranet name under the same domain stops working for staff. The list maintainers report this regularly.
• Apex redirects straight to www on another host: the base domain never sends the header over HTTPS, so preload submission fails and apex includeSubDomains never reaches browsers.
• Header only on the final page: the 301 from apex to www has no HSTS header, which the preload requirements explicitly reject.
• Long max-age before certificate automation: OWASP and hstspreload.org both point to lock-out risk. An expired certificate on an HSTS host is a full outage because users cannot click through. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
• Rollback attempted over HTTP: teams turn off HTTPS to "remove" HSTS. Browsers ignore anything over HTTP, so users stay locked out until max-age expires. Keep HTTPS up and send max-age=0.
• Treating HSTS as privacy neutral: OWASP notes that per-host HSTS state can be abused to fingerprint users without cookies. This is a browser-side concern, but it is a reason not to create large numbers of throwaway subdomains purely for tracking or experimentation on a preloaded domain.

Framework mapping

Practitioner checklist

• Inventory every public and internal name under each domain before enabling includeSubDomains.
• Automate certificate renewal and expiry alerts on every host the policy will cover.
• Redirect HTTP to HTTPS on the same host first, then to any canonical host.
• Send the header over HTTPS only, at the edge, on every response including redirects.
• Ramp max-age through 300 seconds, one week and one month, waiting out each stage.
• Run steady state at one year or more with includeSubDomains.
• Use __Host- session cookies so cookie scope does not depend on HSTS alone.
• Treat preload as a signed-off decision for high-value domains, never a default.
• Keep a tested rollback: max-age=0 over HTTPS before preload, fix forward after it.
• Monitor header drift, HTTP request share and certificate expiry with the metrics above.

Standards and references

• IETF: RFC 6797 HTTP Strict Transport Security (HSTS)
• Chromium: HSTS Preload List Submission
• OWASP: Application Security Verification Standard 5.0
• OWASP: HTTP Strict Transport Security Cheat Sheet
• MDN: Strict-Transport-Security header
• MDN: CSP upgrade-insecure-requests directive
• IETF DNSOP: Service binding and parameter specification via the DNS (SVCB and HTTPS records), editors' source
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Security Headers Guide · TLS Server Configuration Baseline Guide · How TLS Works Guide · Session Hijacking and Cookie Theft Guide