HSTS Preloading: A Practical Guide

What HSTS does

When a user visits http://example.com for the first time, the server redirects them to https://example.com. That redirect happens over plain HTTP — before any TLS is established. An attacker on the same network (coffee shop Wi-Fi, a compromised router) can intercept that initial HTTP request and respond with their own content, or silently proxy the HTTPS session by stripping TLS: the SSL stripping attack.

HTTP Strict Transport Security (HSTS, RFC 6797) addresses this. Once a browser has visited a site over HTTPS and received the Strict-Transport-Security header, it remembers for the duration of max-age that this domain must only be contacted over HTTPS. Future visits bypass the initial HTTP step entirely — the browser upgrades to HTTPS internally before sending any request.

The limitation: HSTS only takes effect after the first successful HTTPS visit. A first-time visitor, or someone who has never visited before, still has no protection. This is the "first-visit problem," and it is why the preload list exists.

The header explained

The header is set by your HTTPS server in HTTP responses:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Each directive:

• max-age: How long in seconds the browser should enforce HTTPS-only. The HSTS preload list requires at least 31536000 (1 year). The recommended value is 63072000 (2 years). After this window expires, the browser will make a plain HTTP request again — so keep it set.
• includeSubDomains: Extends the policy to all subdomains of the domain that sent the header. Without this, api.example.com and mail.example.com can still be reached over HTTP. Required for preload eligibility.
• preload: A signal to preload list operators that you consent to having your domain baked into browsers. This directive itself does nothing in the browser — you still need to submit to hstspreload.org.

The preload list

The HSTS preload list (maintained at hstspreload.org and baked into Chrome, Firefox, Safari, and Edge) contains domains that browsers will always connect to over HTTPS — even on a completely fresh install with no browsing history. These domains have HTTPS enforced before the first byte is sent, eliminating the first-visit problem.

Eligibility requirements:

• Serve a valid HTTPS response on the root domain
• Redirect all HTTP traffic to HTTPS (including on all subdomains)
• Serve the HSTS header on the HTTPS response, not just the redirect
• max-age of at least 31536000 seconds (1 year)
• includeSubDomains directive present
• preload directive present

The commitment this implies: once you are on the preload list, all subdomains must serve valid HTTPS for as long as browsers have your entry. Removing a subdomain from DNS, or letting a certificate expire, will make that subdomain unreachable in browsers. Getting removed from the preload list takes months and you remain in older browser versions for years. Do not submit until every subdomain has working HTTPS.

Deployment checklist

Deploy HSTS safely in stages:

1. Inventory all subdomains. Check DNS for every active subdomain. Each one needs a valid, auto-renewing certificate before you add includeSubDomains.
2. Deploy HTTPS everywhere. Ensure every subdomain redirects HTTP to HTTPS and has a valid certificate. Test certificate renewal.
3. Start with a short max-age. Set max-age=300 (5 minutes) on your production HTTPS responses. Monitor for breakage over several days. This gives you a fast exit if something is wrong — the browser forgets quickly.
4. Increase gradually. 300 → 86400 → 604800 → 2592000 → 63072000. Each step, wait for the previous max-age to expire in testing environments before proceeding.
5. Add includeSubDomains and preload once you are confident in the long max-age with the base domain only.
6. Submit to hstspreload.org.

Common mistakes

• Setting HSTS before HTTPS is fully working: If a user receives the HSTS header and then your certificate expires or HTTPS breaks, the browser will refuse to load the site for the duration of max-age. There is no server-side reset for this — the browser holds the state.
• Sending HSTS on the HTTP redirect: Browsers only honor HSTS headers received over HTTPS. The header on your HTTP-to-HTTPS redirect is ignored.
• Forgetting a subdomain that cannot serve HTTPS: legacy.example.com running an old HTTP-only service will become completely unreachable once includeSubDomains is set and the browser has cached the policy.
• Removing the HSTS header after preloading: The preload list is the source of truth for fresh browsers, not your server. To get removed from the preload list, submit a removal request at hstspreload.org, then wait — it takes months to propagate and years to leave all browser versions.
• Naked vs www confusion: The HSTS header on www.example.com does not cover example.com and vice versa. If you redirect the naked domain to www, set HSTS on both the redirect response's destination and the final HTTPS response of the canonical domain.

How to verify

Check the HSTS header by fetching your domain's HTTPS response and inspecting the headers:

• Confirm Strict-Transport-Security is present on the HTTPS response (not on HTTP redirects)
• Confirm max-age is at least 31536000 for preload eligibility
• Confirm includeSubDomains is present if you intend to preload
• Check preload status at hstspreload.org — it shows whether your domain is pending, preloaded, or ineligible

The TLS inspector checks the HSTS header, redirect chain, and certificate together, so you can see at a glance whether HTTPS is correctly configured end-to-end.

HSTS and HTTPS redirects

HSTS depends on HTTPS redirects being in place, but they are different mechanisms. The redirect (HTTP 301 from port 80) handles clients that have not yet learned the policy. HSTS handles clients that have learned it — they skip port 80 entirely. Both must work correctly. A broken redirect does not affect browsers that already have the HSTS policy cached, but it affects all first-time visitors and any client that does not validate HSTS. Check that your HTTP-to-HTTPS redirect returns a permanent 301 (not 302) and does not introduce redirect loops.