What Is HSTS? HTTP Strict Transport Security Explained

Q: Can I test HSTS without affecting real users?

Yes — start with a very short max-age (300 seconds). Only that browser caches the rule, and it expires in five minutes. Once you're happy, raise to a production value.

Q: What if I accidentally set a very long max-age and need to revert to HTTP?

Set max-age=0 on HTTPS and wait for it to propagate. Browsers will clear the cached rule when they next hit the header. But they must first reach your HTTPS site — if HTTPS itself is broken, there's no recovery path other than waiting for the max-age to expire.

HTTP Strict Transport Security — HSTS — is a single response header that tells every browser: "never connect to this domain over plain HTTP again." Once a browser has seen your HSTS header, it upgrades all future requests to HTTPS before they ever leave the device. No HTTP request reaches your server, and no network attacker gets a window to intercept one.

The problem HSTS solves

Your site might already redirect HTTP to HTTPS — but that first HTTP request is still vulnerable. If an attacker is on the same network (a coffee shop, a hotel Wi-Fi, a shared office), they can intercept it before your redirect fires. This is called an SSL-stripping or downgrade attack: the visitor ends up on an attacker-controlled HTTP page while thinking they're on yours. Cookies, sessions and form data travel in plain text. HSTS closes this window entirely: the browser skips the HTTP request and goes straight to HTTPS — even on the very first connection after the header has been cached.

What the HSTS header looks like

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Breaking it down:

max-age — how many seconds the browser remembers the rule. 31536000 = one year. Start with 300 (five minutes) while testing, then extend once you're confident.
includeSubDomains — applies the rule to every subdomain too. Only add this when all your subdomains support HTTPS — a single HTTP-only subdomain becomes completely unreachable for any browser that has cached the header.
preload — opts your domain into browser preload lists, which hardcode it as HTTPS-only before a browser has ever visited. Requires registration and a long-term commitment.

HSTS preloading

Chrome, Firefox, Safari and Edge ship with a built-in list of thousands of domains that are always HTTPS — before any first visit. This closes the gap that even a cached HSTS header can't cover: the very first connection to a new device. To join the preload list you need:

max-age of at least 31536000 (one year)
includeSubDomains
preload
Registration at hstspreload.org

Preloading is effectively permanent. Removal takes months to propagate through browser releases. Only preload when you're certain every subdomain will stay on HTTPS indefinitely and you have no plans to fall back.

How to set HSTS on your server

The header must appear on HTTPS responses — set it at your web server or CDN, not in HTML.

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Cloudflare: SSL/TLS → Edge Certificates → HSTS. Enable the toggle, then choose your max-age, subdomain inclusion and preload option from the panel — Cloudflare handles the header.

Safe rollout sequence

Confirm your site and all subdomains work on HTTPS without errors.
Set a short max-age (300–3600) and deploy. Check the header is present in DevTools.
Test edge cases: any HTTP-only subdomains, any internal tools, any redirects you control.
Extend to a long max-age (63072000 = two years is a sensible target).
Add includeSubDomains once all subdomains are HTTPS-ready.
Add preload and register only when you're committed for the long term.

Common HSTS mistakes

Setting a long max-age before you've tested. If your site later needs to serve HTTP (rollback, internal tool), browsers that cached the rule can't reach it at all for the duration of max-age.
Adding includeSubDomains prematurely. One HTTP-only subdomain becomes unreachable for every browser that has the rule cached — there's no override, it has to time out.
Setting max-age=0. This tells browsers to delete the HSTS record. Useful during rollback, but don't leave it — it removes all protection.
Delivering HSTS on HTTP responses. Browsers ignore it on HTTP — it must be on HTTPS.

How to check if your site has HSTS

In Chrome DevTools: Network tab → click your main page request → Response Headers. Look for Strict-Transport-Security. If it's absent, your site has no HSTS and the first HTTP request is still unprotected. Also note whether includeSubDomains is present and whether the max-age is long enough to be meaningful.

The quickest check: run a free Kalenfy scan — HSTS is one of the headers we audit alongside CSP, X-Content-Type-Options and your full email-authentication setup, with a plain-English grade.

FAQ

Does HSTS replace the HTTP→HTTPS redirect?

No, they work together. Keep the redirect for first-time visitors and search engines. HSTS removes the HTTP hop for any browser that has already visited and cached the header.

Can I test HSTS without affecting real users?

Yes — start with a very short max-age (300 seconds). Only that browser caches the rule, and it expires in five minutes. Once you're happy, raise to a production value.

What if I accidentally set a very long max-age and need to revert to HTTP?

Set max-age=0 on HTTPS and wait for it to propagate. Browsers will clear the cached rule when they next hit the header. But they must first reach your HTTPS site — if HTTPS itself is broken, there's no recovery path other than waiting for the max-age to expire.