Cybersecurity glossary
What is HTTP Strict Transport Security (HSTS)?
Learn what HTTP Strict Transport Security (HSTS) is, how Strict-Transport-Security keeps browsers on HTTPS, what max-age and preload do, and how to deploy HSTS without locking yourself out.
Definition
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that instructs browsers to interact with a host only over HTTPS for a defined period, reducing the risk of protocol downgrade and cookie hijacking on cleartext HTTP.
Why HSTS matters
HTTPS only helps when users actually use it. Attackers on shared Wi-Fi historically stripped TLS by rewriting links to http:// and intercepting cleartext. HTTP Strict Transport Security (HSTS) closes that gap for returning browsers by remembering that a host must be contacted with HTTPS only.
HSTS is one of the highest-value HTTP security headers when HTTPS is already correctly deployed. Misused, it can also strand users on a domain that cannot present a valid certificate.
How HSTS works
User completes a valid HTTPS visit
The browser receives Strict-Transport-Security on a trustworthy HTTPS response.
Policy is stored
max-age defines how long the host must be treated as HTTPS-only; optional flags extend scope.
Later HTTP attempts upgrade
The browser switches to HTTPS before sending cleartext requests to that host.
Certificate errors fail closed
Users generally cannot click through TLS errors for HSTS hosts as easily as for ordinary HTTPS.
Optional preload
Domains on the preload list get HSTS protection even on first visit in supporting browsers.
Policy expires or renews
Continued HTTPS responses refresh max-age; stopping the header lets policy expire safely over time.
Important directives
max-age
Seconds the policy remains active. Production sites often use months; roll out with shorter values first.
includeSubDomains
Applies HSTS to all subdomains of the host that issued the policy.
preload
Signals intent to be included in browser preload lists; follow current submission rules exactly.
Deployment pitfalls
| Pitfall | Consequence |
|---|---|
| Long max-age before HTTPS is solid | Users cannot reach broken hosts until policy expires |
| includeSubDomains with HTTP-only legacy hosts | Internal tools and forgotten subdomains break |
| Preload without commitment | Removal from browser lists is slow and operationally painful |
| Sending HSTS over HTTP | Browsers ignore it; policy never establishes |
Safe rollout checklist
- Ensure valid certificates and HTTPS on all hosts that will be covered.
- Keep HTTP-to-HTTPS redirects while establishing HSTS.
- Start with a short max-age (minutes/hours) and monitor errors.
- Increase max-age gradually to weeks or months once stable.
- Enable includeSubDomains only after auditing every subdomain.
- Consider preload only for long-lived public sites that meet preload requirements.
- Serve HSTS from the canonical apex and www intentionally; understand host-scoped storage.
- Document rollback: lower max-age first; do not rely on instant preload removal.
The practical takeaway
HSTS tells browsers to stick to HTTPS for your host, defending against SSL stripping and casual cleartext navigations. It amplifies good TLS operations and punishes bad ones.
Deploy it after HTTPS is reliable, grow max-age carefully, and treat preload as a deliberate, hard-to-reverse commitment—not a default checkbox.
Related security terms
HTTPS
The encrypted HTTP transport that HSTS requires browsers to use.
SSL/TLS
The cryptographic protocols underlying HTTPS connections enforced by HSTS.
Man-in-the-Middle (MITM)
The network attacker model HSTS is designed to frustrate for HTTP downgrades.
Content Security Policy (CSP)
Another HTTP security header that complements HSTS but solves different problems.
Frequently asked questions
What is HSTS in simple terms?
HSTS tells a browser: for this website, never use plain HTTP—only HTTPS—for a set amount of time. That helps stop attackers on the network from silently downgrading users to unencrypted connections.
How does the Strict-Transport-Security header work?
When a browser receives the header over a valid HTTPS response, it stores a policy with max-age (and optional includeSubDomains). Later navigations to that host use HTTPS automatically.
What is HSTS preload?
Preload is a browser-maintained list of domains that are treated as HSTS even before the first visit. Sites must meet submission requirements and understand that removal is slow.
Can HSTS break my site?
Yes, if HTTPS is misconfigured, certificates fail, or HTTP-only subdomains still matter. Start with a short max-age, fix HTTPS everywhere you need, then increase duration.
Does HSTS replace a redirect from HTTP to HTTPS?
No. You still need a first HTTPS response to deliver HSTS (unless preloaded). Keep redirects, and use HSTS so browsers stop attempting HTTP afterward.
Should includeSubDomains be enabled?
Enable it when every subdomain can serve correct HTTPS. Otherwise you may force HTTPS onto hosts that are not ready.
Does HSTS encrypt traffic by itself?
No. HSTS only enforces HTTPS usage. Encryption quality still depends on TLS configuration.
References
Explore authoritative guidance and frameworks related to http strict transport security (hsts).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.