An old HTTP bookmark can expose a request before your server redirects it. HSTS changes that sequence by making browsers require HTTPS for known hosts.
Key Takeaways
- HSTS upgrades HTTP URLs before requests leave your browser.
- Learned protection starts after a trusted HTTPS response.
- Long policies and subdomain coverage require dependable HTTPS, including during certificate renewals and CDN migrations.
What Is HSTS?
HSTS means HTTP Strict Transport Security, a browser-enforced policy defined in RFC 6797. Your server sends the Strict-Transport-Security response header over trusted HTTPS. Browsers store the policy for that hostname and ignore headers received over HTTP, where attackers could alter them.
The policy belongs to a hostname, not a specific page, so you cannot enable it only for your login path.
{{cool-component}}
How HSTS Prevents SSL Stripping and Protocol Downgrade Attacks
During an SSL stripping attack, an on-path attacker keeps your browser on HTTP while connecting to the real server over HTTPS. A known HSTS policy prevents that HTTP request and blocks certificate-error bypasses.
An HTTPS redirect needs an initial HTTP exchange; learned HSTS alone leaves first contact exposed. The downgrade addressed is HTTPS to HTTP, not TLS-version negotiation. You configure permitted TLS versions separately at your server or CDN.
How the HSTS Header Works and What Its Directives Control
For an established, preload-ready deployment, the header can be:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age measures seconds of browser retention, refreshed whenever a valid header arrives. includeSubDomains extends the policy to every descendant subdomain. preload signals consent to browser-list submission; it does not automatically list your domain.
Subdomains should also send their own headers because a browser can visit them before learning the parent's policy.
What the HSTS Preload List Is and How to Get Listed
The HSTS preload list ships with browsers, allowing enforcement before a first visit.
Submission through hstspreload.org requires valid HTTPS, an HTTP-to-HTTPS redirect on the same host wherever HTTP is served, and HTTPS-ready subdomains, including internal ones. Your base-domain HTTPS responses, including redirects, need max-age of at least 31536000, includeSubDomains, and preload.
Submit separately, then allow for browser release delays. Inclusion and removal can take months. Preloading is optional; the submission service discourages it because its additional benefit over ordinary HSTS is limited.
{{cool-component}}
How to Roll Out HSTS Without Breaking Your Site
I'd check forgotten subdomains before committing. Use this four-step checklist:
- Inventory subdomains, including internal services; verify valid certificates and HTTPS on every required host.
- Start with max-age=300 on all HTTPS responses, including redirects and errors; keep HTTP-to-HTTPS redirects.
- Test login flows and CDN failover; monitor failures throughout the full current max-age before increasing retention.
- Enable includeSubDomains only after every affected host passes; evaluate preloading as a separate, long-term commitment.
For a multi-CDN strategy, match headers and TLS readiness across providers. Inspect browser-facing responses, since edge configuration can override your origin's header.
max-age=0 over HTTPS clears a learned policy after receipt, but not built-in preload entries. Simply removing the header leaves previously stored policies active until expiry.
Conclusion
Deploy HSTS once HTTPS is reliable, then extend its scope carefully. Keep certificates valid throughout the policy lifetime, including during provider migrations.
FAQs
Can HSTS Break a Site If HTTPS Is Not Ready?
Yes. Once a browser knows the policy, missing HTTPS or an invalid certificate can make the site inaccessible. With includeSubDomains, the same risk extends to covered subdomains. Restore working HTTPS first; changing the header cannot help browsers that cannot establish a trusted connection to receive it.
How Long Should an HSTS max-age Directive Be Set?
Begin with 300 seconds while you validate behavior, then increase gradually after successful tests. A year is a common production setting and the minimum for preload submission. Each received header refreshes expiry, so returning visitors keep enforcing the policy beyond its original installation date.
Does HSTS Protect Against All Man-in-the-Middle Attacks?
No. HSTS prevents HTTP downgrades when its policy is known and stops users bypassing certificate errors. It cannot defeat an attacker with a certificate the browser trusts or a compromised endpoint. You still need sound TLS configuration and separate protections for application-level threats.
Does HSTS Apply to Subdomains Without the includeSubDomains Directive?
No. Without includeSubDomains, a learned policy covers only the issuing hostname. A subdomain can send its own HSTS header and establish independent protection. However, an already-known ancestor policy with includeSubDomains still applies: a child cannot opt out simply by sending max-age=0.
How Does HSTS Behave When CDN Terminates TLS?
When a CDN terminates TLS, the browser enforces HSTS on its connection to that CDN for your hostname. The edge can add the header or forward it from your origin. HSTS does not secure the edge-to-origin connection; configure HTTPS and certificate validation there separately.
