HSTS tells browsers to require HTTPS for a period of time. Enable it only after HTTPS is reliable, because cached HSTS policy can keep a site inaccessible even after a mistaken dashboard setting is reversed.
IN THIS ARTICLE
Check access and requirements
Inventory the main domain and all subdomains before considering includeSubDomains. Confirm certificate renewal, HTTPS redirects and a recovery plan. Treat preload as a separate long-term commitment.
01 Enable HSTS only after all required hostnames support HTTPS
- Verify valid HTTPS across every hostname you intend the policy to cover. Correct mixed content and redirect loops first.
- Open SSL/TLS > Edge Certificates and the HSTS configuration. Read and acknowledge the consequences.
- Start with a considered max-age and leave includeSubDomains disabled unless all affected names are ready. Do not enable preload as a routine checkbox.
- Save and inspect the HTTPS response’s Strict-Transport-Security header. Test the site from a fresh browser and the ordinary application paths.
- Monitor certificates and retain HTTPS throughout the policy lifetime. If disabling HSTS, serve max-age=0 over valid HTTPS and account for clients that have not revisited.
Confirm the expected result
The intended HTTPS responses should carry one coherent HSTS policy. The application should remain usable with no certificate exceptions or insecure dependencies.
Resolve setup problems
An existing browser policy persists until it expires or receives a valid clearing response. Preload removal involves browser-list propagation and is not an instant reversal. Avoid moving an HSTS-covered site to an HTTP-only destination.
Does includeSubDomains affect a forgotten test hostname?
Yes, it can require HTTPS there too. Inventory old, delegated and externally hosted subdomains before enabling a parent policy that covers them.