Do Not Preload HSTS Until Every Subdomain Is Ready

• Use ordinary HSTS first. Raise max-age in stages while you watch for broken hosts.
• Add includeSubDomains only after every present and future subdomain can use valid HTTPS.
• Preload only when that commitment is worth it.

HSTS tells a browser to use HTTPS for later visits. Preloading goes further: the rule ships inside the browser, so even the first visit starts with HTTPS.

That sounds like a simple security upgrade. It is also a broad promise about your domain tree. A preloaded base domain covers every subdomain and nested subdomain, including names that are internal or not public today.

The official preload service says HSTS is recommended, but HSTS preloading is not. Treat preload as a final commitment, not the first header you add.

Start with ordinary HSTS

Serve the Strict-Transport-Security header only over HTTPS. A browser that receives it stores the policy for the number of seconds in max-age. Later HTTP requests are upgraded.

Strict-Transport-Security: max-age=300

The five-minute value above is a labelled rollout example, not a universal setting. Begin with a period your team can observe. Then extend it only after redirects, certificates and key pages stay healthy.

Removing the header does not erase a policy that a browser already stored. The old rule remains until it expires. Sending max-age=0 over valid HTTPS asks that host to delete its stored policy, but the browser must first reach that HTTPS response.

Inventory the whole domain tree

Before includeSubDomains, build a list from public DNS, certificate records, infrastructure files and service owners. Look beyond www. Old campaign sites, vendor portals, device consoles and forgotten test names often live deeper in the tree.

For each active host, check four things: a valid certificate, an HTTPS listener, same-host HTTP-to-HTTPS behavior, and the application itself. A certificate alone does not prove the HTTPS service works.

Also decide how future hosts will get certificates before they receive traffic. Future names inherit this rule.

The certificate rollout guide helps verify that renewed certificates reached each public path. Use the support calendar to name owners for older appliances and services.

Separate HSTS from preload

HSTS works without a preload list. That gives returning browsers the HTTPS-only rule after one secure visit. It also lets you learn with a short policy before making a longer promise.

Preload closes the first-visit gap. Chrome's service says that benefit is now small because major browsers already try to upgrade many HTTP navigations. An active attacker can still matter, but not every site needs the extra commitment.

If you proceed, the current submission rules require a valid certificate, same-host HTTP-to-HTTPS redirects where port 80 is used, HTTPS on all subdomains, and this header on the base domain:

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

One year is the minimum accepted max-age. The service's example uses two years. Do not copy either value into production until your staged rollout has proved the domain tree.

Run a no-HTTP release gate

1. Check the base domain. HTTP must redirect to HTTPS on the same host, and the HTTPS response must carry the intended header.
2. Check every known subdomain. Include nested names, redirects, alternate ports used by browsers and vendor-managed hosts.
3. Check certificate failure. HSTS users cannot click through a certificate warning. Make renewal and outage ownership explicit.
4. Hold the ramp. Keep each shorter max-age long enough to see regional, device and rarely used host failures.
5. Record the decision. Name the domain owner, certificate path, incident route and reason preload is worth keeping.

This is a procedure for your team to run. TechWeb did not scan your DNS, certificates, browsers or private hosts.

Plan removal before submission

Removal is not a quick rollback. The preload service warns that a change can take months to reach users through browser updates, and it cannot promise how other browsers will handle the list.

If a future service cannot support HTTPS, a preloaded parent can make it unreachable in affected browsers. That is why a working max-age=0 response is not enough protection against a preload mistake.

Keep the decision with other high-impact web controls. The CSP rollout guide uses report-only mode for a different risk, while the Fetch Metadata guide adds a request filter without changing transport policy.

Frequently asked questions

Does HSTS require preload?

No. A site can send HSTS without joining a browser preload list. Preload mainly covers the first visit.

Can includeSubDomains break an HTTP-only host?

Yes. A browser applies the parent policy to nested hosts and tries HTTPS. The host can become unreachable when it lacks a valid HTTPS service.

Can I undo preload with max-age=0?

Not by itself. That can clear a dynamic policy after an HTTPS response, but removal from browser preload lists can take months.

Sources

IETF RFC 6797: HTTP Strict Transport Security · Chrome HSTS Preload List Submission · MDN: Strict-Transport-Security. Requirements and browser behavior can change; recheck them before submission.