HTTP Strict-Transport-Security (HSTS) Explained
The HTTP Strict-Transport-Security (HSTS) response header tells a browser to only ever connect to a site over HTTPS, never plain HTTP, for a set period. Once a browser has seen the header, it automatically upgrades every request to that domain to HTTPS and refuses to connect if the certificate is invalid — closing the window that SSL-stripping man-in-the-middle attacks rely on.
What is the Strict-Transport-Security header?
Defined in RFC 6797, HSTS solves a specific problem: even on an HTTPS site, the very first request a user makes is often plain HTTP (they type example.com, not https://…), and that unencrypted request can be intercepted and downgraded. HSTS instructs the browser to remember the site as HTTPS-only, so after the first secure visit it never sends an HTTP request there again.
HSTS directives
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload| Directive | Meaning |
|---|---|
max-age | How long (in seconds) the browser enforces HTTPS-only. 31536000 is one year, the common value. |
includeSubDomains | Applies the policy to every subdomain, not just the exact host. |
preload | Signals that the domain may be added to the browser preload list, so HTTPS is enforced even on the very first visit. |
The first-visit gap and the preload list
Plain HSTS only protects users after their first successful HTTPS visit. To close that initial gap, browsers ship a built-in HSTS preload list of domains hard-coded as HTTPS-only. Adding preload to your header and submitting the domain means even a brand-new visitor never makes an HTTP request. Preloading is powerful but hard to undo, so only enable it once you are certain the whole domain and its subdomains are permanently HTTPS.
How to check HSTS
See whether a site sends the Strict-Transport-Security header, and with what max-age, using the free HTTP headers checker. Because HSTS depends entirely on a valid certificate, it pairs directly with your TLS setup — see the SSL certificate monitoring and invalid certificate guides.
Common HSTS mistakes
- A very short
max-age. A few minutes gives almost no protection. Use a long value (a year) once you are confident in HTTPS. - Omitting
includeSubDomains. Without it, a subdomain served over HTTP remains a downgrade target. - Enabling
preloadtoo early. If any subdomain still needs HTTP, preloading will break it — and removal from the list takes a long time. - Sending HSTS over plain HTTP. The header is only honoured over HTTPS; on an HTTP response it is ignored.
Related security headers
HSTS enforces the transport; other headers protect the content: Content-Security-Policy (injection/XSS), X-Frame-Options (clickjacking), and X-Content-Type-Options (MIME sniffing).
Frequently asked questions
Do I need HSTS if I already redirect HTTP to HTTPS?
Yes. A redirect still starts with an interceptable HTTP request. HSTS makes the browser skip HTTP entirely on future visits, which a redirect cannot do.
What max-age should I use for HSTS?
One year (31536000 seconds) is the widely recommended value, and it is required for submission to the preload list. Start lower while testing if you prefer, then raise it.
Can HSTS lock me out of my own site?
If you enable HSTS (especially with preload) and then cannot serve valid HTTPS, browsers will refuse to connect. Only enable it once your certificate and HTTPS are reliable across the domain.