Enabling HSTS and Preload Safely

Every mainstream static host redirects HTTP to HTTPS, and every HTTPS page carries a valid certificate. That feels finished, but a redirect still means the reader's browser sent one request in plain text first, and anyone positioned on the network — a hostile Wi-Fi hotspot, a compromised router — can answer that request instead of your server. Strict-Transport-Security tells the browser never to make that plain-text request again. The HSTS preload list goes one step further and builds your domain into the browser itself, so even a reader's very first visit is HTTPS-only.

Both are one header. Both are also sticky in a way almost no other web setting is: browsers remember HSTS for as long as you told them to, and preload list entries ship inside browser releases. A mistake — an internal tool on a subdomain that only works over HTTP — can make that subdomain unreachable for months. This guide rolls HSTS out in stages that make mistakes cheap. It is part of Security Headers and Hardening for Static Sites.

Prerequisites

• HTTPS working on the apex domain and every subdomain you intend to keep.
• Access to DNS for the domain, to list every subdomain.
• A way to set response headers at the host — _headers, vercel.json, a CloudFront response headers policy, or server config.

Step 1: Inventory Every Subdomain

includeSubDomains applies the policy to every name under the domain, including ones you forgot. Before touching the header, list them from DNS and from certificate transparency logs, which record every certificate ever issued for the domain:

# from DNS (zone export or provider API), then from CT logs:
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | tr '\n' '\n' | sort -u > ct-names.txt
while read -r host; do
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "https://$host/")
  echo "$code $host"
done < ct-names.txt

On the site used here, DNS listed 9 subdomains; certificate transparency revealed 14, including a 2019 conference microsite, a status page on a third-party service and an internal metrics dashboard. Two of them failed on HTTPS: the old microsite (certificate expired) and a printer-management page on an office subdomain that only spoke HTTP.

The printer page moved to a separate internal domain; the microsite's DNS record was deleted after its content was archived into the main site. Only then was the domain ready.

Step 2: Ramp max-age in Stages

Start with a short lifetime and no subdomains, increase over weeks, and add includeSubDomains only once the inventory is clean:

# _headers — stage 3
/*
  Strict-Transport-Security: max-age=604800; includeSubDomains

At each stage, watch for reports of unreachable pages — support tickets, 4xx spikes in edge logs for subdomains, and synthetic checks against every subdomain from the inventory, like those described in Uptime and Synthetic Checks for Static Sites. The ramp exists so a mistake found at stage 3 costs at most a week.

Step 3: Decide on Preload

With a year-long policy covering subdomains, the domain qualifies for the HSTS preload list at hstspreload.org. Preloading removes the last gap — a reader's first-ever visit — and it is what large, security-sensitive sites do. It also has costs that do not apply to the header alone:

• Every subdomain, forever. Any future subdomain must serve HTTPS from its first day. A marketing agency spinning up campaign.example.com on a plain-HTTP host will not work.
• Slow removal. Removal requests are processed, then shipped in browser releases; users on old browser versions keep the entry longer. Plan on months.
• The whole registrable domain. You cannot preload docs.example.com alone; the entry is for example.com and everything beneath it.

For a documentation or marketing site on a domain the organisation fully controls, with DNS changes going through review, preload is a reasonable final step. For a domain shared with many teams or agencies, the header with includeSubDomains gives nearly all the benefit without the permanence.

Step 4: Verify

After each stage, confirm the header is present on every response type — HTML, assets, redirects and error pages — because some hosts apply header rules only to successful responses:

for p in / /guides/ /does-not-exist/ /_astro/app.js; do
  printf '%-22s ' "$p"; curl -sI "https://example.com$p" | grep -i '^strict-transport' || echo MISSING
done
curl -sI http://example.com/ | head -3     # must be a 301 to https, no HSTS on the HTTP response

Browsers ignore HSTS on plain-HTTP responses by design, so its absence there is correct. Chrome's chrome://net-internals/#hsts page shows whether the browser has stored the policy for the domain and with what expiry, which is useful when testing the ramp.

Keeping New Subdomains Compliant

Once includeSubDomains is live, the risk moves from the past to the future: the next subdomain someone creates. Three guard rails keep it from becoming an outage. First, route DNS changes through a pull request against a DNS-as-code repository (Terraform, OctoDNS, or the provider's config export) rather than a web console, and add a CI check that every new record points at a host known to serve HTTPS — a CDN, a static host, or a load balancer with a managed certificate. Second, add every subdomain to the synthetic HTTPS checks the moment it is created, so a missing certificate alerts within minutes rather than when a reader reports it. Third, document the rule where agencies and other teams will see it: "every name under example.com must serve valid HTTPS from its first request". Most breakages under HSTS are not technical surprises; they are someone who never heard of the policy spinning up a quick landing page on a host that defaults to plain HTTP.

The same discipline makes certificate expiry less likely to matter. With HSTS active, browsers refuse to let readers click through a certificate warning, so an expired certificate on any subdomain becomes a hard outage rather than a scary-looking page. Automated renewal — standard on every static host and on Caddy — plus an expiry alert at fourteen days covers it.

Measured Impact

Pitfalls & Rollback

• Skipping the subdomain inventory. includeSubDomains will find the forgotten HTTP-only host for you, in the worst way. Check certificate transparency logs, not just DNS.
• Setting a year on day one. A mistake then costs a year. Ramp.
• Preloading a shared domain. If other teams or agencies create subdomains, preload binds them too. Get agreement first.
• Header missing on error pages. Verify redirects, 404s and assets, not just the homepage.
• Rollback: to back out, serve max-age=0. Browsers that see it drop the policy immediately; those that never return keep it until expiry, which is exactly why the ramp keeps early stages short. Preload removal is a separate request at hstspreload.org and takes months.

Conclusion

HSTS is a one-line header with a long memory. Inventory every subdomain from DNS and certificate transparency, fix or retire anything that cannot serve HTTPS, ramp max-age from minutes to a year over about seven weeks, and add includeSubDomains only once the inventory is clean. Preload is the optional last step — the right choice for a domain one team fully controls, and a commitment to weigh carefully for one shared across many.

FAQ

What does HSTS protect against?

It stops browsers from ever connecting to your domain over plain HTTP after they have seen the header once. That closes the window where an attacker on the network could intercept the first HTTP request and redirect or modify it before the HTTPS redirect happens.

Why not set a one-year max-age straight away?

Because browsers remember it for the full duration. If a subdomain or path turns out to need plain HTTP, readers who saw the header cannot reach it until the max-age expires. Starting with minutes and increasing in steps limits the damage of a mistake.

Is the HSTS preload list reversible?

Technically yes, but slowly. Removal requests take effect only as browsers ship new versions, and users on older versions keep the entry for months. Treat preloading as a long-term commitment for the domain and all its subdomains.

Do static hosts already redirect HTTP to HTTPS?

Most do, but a redirect alone still lets the first request go over HTTP. HSTS makes the browser upgrade the request itself before it leaves the device, and preload extends that to readers who have never visited.

Related

• Parent: Security Headers and Hardening for Static Sites — the rest of the header set.
• Custom Domains and TLS on Cloudflare Pages — getting HTTPS right before HSTS.
• Writing a Content Security Policy for a Static Site — the header that pairs with HSTS.
• Serving a Static Site with Caddy — automatic HTTPS when self-hosting.
• Running Smoke Tests Against a Preview URL — asserting headers on every deploy.