Why Your Site Needs an HSTS Header (And How to Check If It's Missing)

Strict-Transport-Security — HSTS — is one line in a server config, costs nothing, breaks nothing when configured correctly, and is one of the most consistently forgotten security headers on the web. Even sites that otherwise take security seriously miss it, because unlike a broken feature, a missing header never generates an error, a support ticket, or a stack trace. It just quietly leaves a gap.

What HSTS actually does

Without HSTS, a browser that's told to visit example.com (no scheme specified — which is what happens when someone types a bare domain, clicks an old bookmark, or follows a link someone wrote without https://) will make its first request over plain HTTP, then get redirected to HTTPS by the server. That first request, before the redirect, is sent in the clear — and on an untrusted network (public wifi, a compromised router), an attacker positioned in the middle can intercept it and strip the redirect, keeping the victim on HTTP for the entire session. This is a real, well-known attack class called SSL stripping.

The Strict-Transport-Security header tells the browser: "remember, for the next N seconds, to never even attempt an HTTP connection to this domain — go straight to HTTPS, internally, before any request leaves the machine." Once a browser has seen the header once, the vulnerable first-request-over-HTTP moment simply stops existing for that browser, for as long as the header's max-age says.

The header, correctly configured

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

• max-age=31536000 — one year, in seconds. This is the industry-standard value; shorter defeats the purpose (the protection lapses if a visitor doesn't return within the window), and there's rarely a reason to go lower.
• includeSubDomains — applies the same protection to every subdomain, not just the exact host that sent the header. Add this once every subdomain is confirmed to actually support HTTPS — enabling it against a subdomain that doesn't have a valid certificate will break that subdomain for anyone who's already seen the header.

There's also an optional preload directive and a corresponding submission process (hstspreload.org) that bakes the HTTPS-only requirement directly into browser source code, so even a visitor's very first-ever request to the domain is protected — worth it for a domain that's fully committed to HTTPS everywhere, permanently, since preload list removal is slow.

Why it's so commonly missing

HSTS doesn't get set by default on most web servers — it has to be added explicitly, usually in the same vhost config as the HTTPS redirect itself, and it's easy to set up the redirect (which visibly works — you can watch it happen in a browser) and stop there, since the header's absence produces no visible symptom at all. We found this exact gap on three of our own network's domains during early testing of this product — sites that had been correctly serving HTTPS for years, just without the one header that closes the first-request gap.

Checking for it

From a terminal: curl -sI https://example.com | grep -i strict-transport-security. No output means it's missing. That's the entire check — which is exactly why it belongs in something that runs automatically rather than something you remember to type.