HSTS and Enforcing HTTPS Everywhere
How HTTP Strict Transport Security closes the gap left by relying on redirects alone to enforce encryption.
Core Concept
HTTP Strict Transport Security (HSTS) instructs browsers to only ever connect to a domain over HTTPS, even if a user types or clicks an HTTP link.
Without HSTS, a user's very first request can still go out over plain HTTP before any redirect happens, creating a brief but real window for interception.
How HSTS Works
Once a browser receives an HSTS header, it remembers the policy and applies it automatically going forward.
- Server sends Strict-Transport-Security header over HTTPS
- Browser caches the policy for the specified max-age
- All future requests are automatically upgraded to HTTPS, even if HTTP is typed
Client-Side Enforcement
HSTS enforcement happens entirely in the browser before any network request is even sent, not via a server-side redirect.
Key Directive Options
The HSTS header supports a few important directives that control its scope and strength.
- max-age — how long the policy is cached, in seconds
- includeSubDomains — extends the policy to all subdomains
- preload — opts into the browser preload list
The HSTS Preload List
The preload directive lets domains submit themselves to a hardcoded list built into major browsers, closing even the first-connection gap entirely.
Once preloaded, a browser will enforce HTTPS for that domain from the very first connection, before ever receiving the site's HSTS header.
Effectively Permanent
Removal from the HSTS preload list is a slow, manual process — domains should be fully committed to HTTPS everywhere before submitting.
Rollout Considerations
HSTS is powerful but unforgiving of mistakes, since it can't simply be reversed for users who've already cached the policy.
- Start with a short max-age before committing to a long one
- Confirm every subdomain supports HTTPS before using includeSubDomains
- Test thoroughly before submitting to the preload list
Real-World Implementation
HSTS is standard practice across security-conscious production deployments.
- Financial and authentication services using preloaded HSTS
- Gradual max-age escalation during initial rollout
- CDNs and reverse proxies applying HSTS centrally
Combined with HTTPS redirects and a valid certificate, HSTS closes nearly every practical path an attacker has for downgrading a connection to plain HTTP.
Common Mistakes to Avoid
A few common mistakes make HSTS rollout riskier than it needs to be.
- Setting a long max-age before confirming the site works reliably over HTTPS everywhere.
- Enabling includeSubDomains without verifying every subdomain actually supports HTTPS.
- Submitting to the preload list before HTTPS is fully and reliably committed to.
- Assuming HSTS can be reversed quickly if a mistake is discovered later.
- Overlooking that HSTS enforcement happens entirely client-side, before any request is sent.
- Overlooking that HSTS doesn't protect the very first connection before any header is received.
- Assuming HSTS alone eliminates the need for HTTPS redirects entirely.
- Failing to test HSTS behavior explicitly across subdomains before enabling includeSubDomains.
- Overlooking that HSTS preload list removal is a slow, manual, and not-guaranteed process.
- Assuming HSTS applies retroactively to browser sessions already in progress.
- Failing to coordinate HSTS rollout with any subdomains still on shared infrastructure.
- Overlooking that HSTS preload submission requires meeting specific eligibility criteria first.
Best Practices Checklist
These practices lead to a safer, more reliable HSTS deployment.
- Start with a short max-age before committing to a long-lived policy.
- Confirm every subdomain supports HTTPS before enabling includeSubDomains.
- Test thoroughly across the entire domain before submitting to the preload list.
- Treat preload list submission as a long-term, hard-to-reverse commitment.
- Monitor for any HTTP-only resources that could break once HSTS is enforced.
- Combine HSTS with the preload list for domains needing first-connection protection.
- Keep HTTPS redirects in place as a complementary safeguard alongside HSTS.
- Test subdomain behavior thoroughly before enabling includeSubDomains in production.
- Treat preload list submission as a serious, difficult-to-reverse long-term commitment.
- Understand that HSTS policy applies to future connections, not retroactively to an active session.
- Coordinate HSTS rollout carefully with any subdomains sharing infrastructure that may not yet support it.
- Review the HSTS preload list's specific eligibility criteria before attempting submission.
Frequently Asked Questions
Frequently asked questions about HSTS.
What problem does HSTS actually solve?
It closes the gap left by redirect-based HTTPS enforcement — the risky first request that can still go out over plain HTTP before any redirect happens.
Can HSTS be undone quickly if something goes wrong?
Not easily — cached HSTS policies in users' browsers can't be revoked remotely, making a long max-age combined with a misconfiguration risky.
What does the includeSubDomains directive do?
It extends the HSTS policy to every subdomain, including ones that may not yet support HTTPS, so it needs careful verification first.
Is HSTS preloading permanent?
Effectively close to it — removal from the preload list is a slow, manual process, so it should only be pursued once HTTPS is fully committed to.
Does HSTS rely on a server-side redirect?
No — enforcement happens entirely in the browser before any network request is even sent, which is what makes it stronger than redirects alone.
Does HSTS protect the very first connection to a site?
Not without preloading — the header itself only takes effect after a browser has received it once, leaving a first-connection gap unless preloaded.
Can HTTPS redirects be removed once HSTS is enabled?
It's safer to keep them as a complementary safeguard, since not every client will have already cached the HSTS policy.
What's the risk of enabling includeSubDomains too quickly?
Any subdomain not yet supporting HTTPS will become inaccessible, so thorough testing beforehand is essential.
Is it easy to remove a domain from the HSTS preload list?
No — removal is a slow, manual process, which is why preload submission should be treated as a serious long-term commitment.
Does enabling HSTS affect a browser session already open?
No — the policy applies going forward to future connections, not retroactively to a session already established before the header was received.
Can any domain submit to the HSTS preload list?
No — specific eligibility criteria, including a sufficiently long max-age and includeSubDomains, must be met before submission is accepted.
Check HSTS Configuration
Run a security headers scan to see whether HSTS is properly configured on a domain.
Launch Tool →