Enable HSTS only after the required website names work reliably over HTTPS and certificate renewal is under control. HSTS tells supporting browsers to remember that the host must use HTTPS, which makes certificate mistakes harder for visitors to bypass.
01 Roll out a deliberate policy
- Inventory the main domain, subdomains, webmail, legacy applications and external services using your names. Identify any service that still depends on browser access over HTTP.
- Fix certificate coverage, trust chains, mixed content and redirects. Verify renewal responsibility at the origin and any proxy.
- Start with a short trial lifetime, such as
Strict-Transport-Security: max-age=300, delivered on HTTPS responses through the supported server or proxy setting. - Inspect the response header and test the affected workflows. Remove duplicate or conflicting HSTS settings across application and proxy layers.
- Increase the lifetime after the trial is successful. Add
includeSubDomainsonly after confirming all current and planned subdomains can meet the policy. - Treat browser preload submission as a separate commitment. Review its current requirements and the difficulty of reversing it before opting in.
Common questions
Does removing the header immediately turn HSTS off?
A browser can retain the previous policy until it expires. A supported removal response uses max-age=0 over working HTTPS; preload removal has a separate process.
Should I add every suggested security option for a higher test score?
Apply settings that fit the actual service. A long policy or all-subdomain coverage can break a forgotten application despite improving a scanner's score.
Does HSTS replace certificate monitoring?
No. Reliable renewal becomes especially important because returning browsers enforce HTTPS and reject invalid certificates. Test renewal before extending the policy lifetime.