how to enable HSTS preload for your domain
Walks through enabling HSTS preload for a domain so browsers always use HTTPS, even on first visit. Use this when a team wants to harden a production domain against protocol downgrade attacks and is ready to commit every subdomain to HTTPS. Not for fixing mixed-content warnings or for sites that still serve anything over plain HTTP.
TL;DR
HSTS preload is a list browsers ship with that forces HTTPS for your domain from the very first visit. You opt in by sending a Strict-Transport-Security header with preload on your HTTPS responses, submitting at hstspreload.org, and waiting for the change to propagate. This is a one-way door, so get every subdomain on HTTPS first.
The query
how to enable HSTS preload for your domainUse this when
- You run a production domain and want browsers to default to HTTPS before any redirect even happens
- You are closing out a TLS hardening checklist and HSTS preload is the last gap
- Your site had protocol downgrade or cookie-skimming concerns and you want the strongest browser-level guarantee
- You control the whole domain including all subdomains and can keep them on HTTPS forever
Not for
- Sites that still serve any content over plain HTTP anywhere, even a forgotten subdomain
- Fixing mixed content, expired certs, or redirect loops; those get fixed separately
- Testing locally or on staging domains you might tear down; preload removal takes months
- Deciding between TLS providers or cert types; this is purely about the browser preload list
Steps
- Get all of HTTPS working everywhere on the domain. Every subdomain must serve HTTPS with valid certs, including www, mail, and internal ones you forgot about. Use a subdomain scanner to enumerate them. Expected output: a complete subdomain list with every entry loading over HTTPS.
- Set the HSTS header with the preload flag. Your HTTPS responses should include
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Start with a small max-age for a week to catch mistakes before committing to two years. Expected output:curl -sI https://example.com/shows the header with your chosen max-age. - Verify the header is on every HTTPS response, not just the homepage. Check an API path, a 404 page, and at least one subdomain. Redirect chains from HTTP to HTTPS count too, the final HTTPS response must carry it. Expected output: the header is present everywhere you checked.
- Submit at hstspreload.org. Enter your domain, fix whatever the checker complains about, and submit the form. Expected output: the checker shows all green and your submission is accepted.
- Wait and confirm. Preload list updates roll out with browser releases, which takes weeks to months. After a few releases, check in a fresh browser profile that typing the bare domain goes straight to HTTPS with no HTTP hop. Expected output: fresh-profile test shows direct HTTPS, no plain HTTP request in devtools.
- Remember removal is slow. If you ever need to drop out, you remove the header, request removal, and wait months for browsers to catch up. Expected output: this documented as accepted risk in your runbook before you opt in.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_p63cWESnO6RkOedT0U3qWQ