HTTP Strict Transport Security (HSTS)

Summary

HSTS (HTTP Strict Transport Security) forces browsers to only connect to a site over HTTPS, protecting against protocol downgrade attacks, cookie hijacking, and browsing history leaks. The HSTS preload list hardcodes this policy into browsers so even the first visit is protected, but the site now explicitly recommends against preloading for most cases due to the difficulty of reversal and the fact that modern browsers already auto-upgrade HTTP to HTTPS.

Key Insight

• HSTS solves three specific attack vectors from on-path attackers: browsing history leaks (HTTP URLs visible on the wire), protocol downgrades (attacker rewrites HTTPS redirect to HTTP), and cookie hijacking (attacker modifies cookies on HTTP requests before redirect).
• The preload list was once considered best practice, but the page now states: “HSTS preloading is not recommended.” Modern browsers (Chrome, Safari) auto-upgrade all HTTP navigations to HTTPS regardless of HSTS policy, making preloading’s marginal benefit minimal.
• Preloading is essentially irreversible - removal takes months to propagate through browser update cycles. Projects and tools should not enable the preload directive by default, as site operators regularly get stuck on the list without realizing all subdomains must support HTTPS.
• The recommended deployment is staged ramp-up of max-age: 5 minutes, then 1 week, then 1 month - waiting the full duration at each stage to catch issues before committing to longer enforcement.
• If you do preload, requirements are strict: valid cert, HTTP-to-HTTPS redirect on same host, all subdomains over HTTPS, and HSTS header with max-age >= 31536000 (1 year), includeSubDomains, and preload directives.