Your site probably already redirects HTTP to HTTPS. Most sites do. So it is fair to ask what HSTS adds that the redirect does not.
The answer is a window of exposure that the redirect leaves open, and that HSTS closes.
The gap a redirect leaves open
When someone types your domain into a browser without specifying https, the browser's default first request can go out over plain HTTP. Your server answers that request with a redirect to HTTPS, and from then on the connection is encrypted.
But that first request happened in the clear. On a hostile network, an open coffee shop wifi, a compromised router, anything in the middle, that single unencrypted request is an opportunity. An attacker positioned between the visitor and your server can intercept it and keep the visitor on a connection the attacker controls, instead of passing along your redirect.
The visitor sees something that looks like your site. The padlock never appears, but most people do not check.
This is not a theoretical curiosity. It is the textbook downgrade attack, and the redirect alone cannot prevent it, because the redirect only works if the first request safely reaches you.
What HSTS actually does
HSTS stands for HTTP Strict Transport Security. Mechanically, it is one response header your server sends over HTTPS:
- the header tells the browser: for this domain, use HTTPS only
- the browser remembers that instruction for a duration you specify, commonly six months or a year
- for as long as the instruction is remembered, the browser refuses to send any plain HTTP request to your domain, ever, and upgrades every attempt to HTTPS internally before it leaves the device
The unencrypted first request stops existing for returning visitors. There is nothing for an attacker to intercept.
HSTS also hardens certificate errors. On an HSTS site, a browser will not offer the "proceed anyway" escape hatch when the certificate is invalid. That is deliberate. It removes the option of clicking through a warning that, on a site promising strict transport security, should never be clicked through.
The preload list, briefly
There is still a tiny gap: a visitor's very first visit ever, before the browser has seen your header once. The HSTS preload list closes it. Browsers ship with a built-in list of domains that are HTTPS-only from the factory, and you can submit your domain to it.
Preload is worth knowing about, but it deserves respect. It is hard to undo on any useful timescale. Treat it as a commitment, not a checkbox.
The honest caveat before you enable it
HSTS has one real operational risk: it does exactly what it says, even when that is inconvenient for you.
If you enable HSTS with a long duration and later need to serve anything over plain HTTP, on the apex domain or, if you used the includeSubDomains option, on any subdomain, you cannot. Browsers that remember your header will refuse, for the full remaining duration. There is no server-side override, because the whole point is that the browser stops trusting plain HTTP regardless of what the network claims.
The standard rollout respects this: start with a short duration, confirm everything on the domain and its subdomains genuinely works over HTTPS, then raise the duration. Boring and incremental is the correct shape here.
Why HSTS belongs in monitoring, not just setup
Here is the part that gets missed. HSTS is a header, and headers are configuration, and configuration drifts.
The header is typically set in a CDN dashboard, a server config file, or a hosting platform setting. All of those get rebuilt, migrated, and edited. A platform migration, a CDN change, a config rewrite during an unrelated fix, any of these can silently drop the header.
And when it drops, nothing visibly breaks. The site loads. The padlock shows. Returning visitors are still protected by their remembered instruction, which masks the regression for months. Meanwhile every new visitor is back to the unprotected first request, and the remembered protection is quietly expiring user by user.
A failure mode that is invisible on the day it happens and degrades gradually afterward is precisely the kind of thing one-time setup cannot defend against. It needs a recurring check: is the header still present, is the duration still what we chose, did anything change since last week?
That is the lens Site Clinic applies to security headers generally. Not a deep penetration test, and it is worth saying plainly that header monitoring is a narrow check, not a security audit. What it does is answer one small question on a schedule, so a silent regression gets caught in days instead of being discovered during some future incident.
What to check on your own site today
Open your homepage over HTTPS and look at the response headers in your browser's developer tools, or use any free header checker. You are looking for a Strict-Transport-Security header.
If it is there, note the max-age value and whether includeSubDomains is set. Write down what you found, so future-you can tell whether it changed.
If it is missing, add it with a short duration first, verify your subdomains all work over HTTPS, then extend.
Either way, make the check repeatable. HSTS is one line of configuration that removes an entire class of attack. The only way it fails you is by quietly not being there anymore, and that is a problem monitoring exists to solve.