Skip to content
All tutorials

/tutorials/hsts-explained

HSTS Explained: What It Protects and What It Does Not

Why telling a browser to always use HTTPS closes a gap a valid certificate alone leaves open, and what to check before turning it on.

5 min read

Run Security Headers

The gap a certificate alone leaves open

A valid certificate protects a visitor once they are actually connected over HTTPS, but it does nothing about the moment before that connection is made. Someone who types a domain without https in front of it, or follows an old link that still points at the plain HTTP version, can be sent to the encrypted version by a redirect, or can be intercepted before that redirect ever happens by whoever controls the network they are on. The Strict Transport Security header, HSTS for short, closes this specific gap.

How it actually works

A typical HSTS header

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

Once a browser has seen this header from a domain, it remembers for the duration set by max-age, in seconds, and will automatically rewrite any future request to that domain to use HTTPS before a single byte is sent over the network, without waiting for a server side redirect. This means the vulnerable moment, a plain HTTP request going out before a redirect can happen, simply never occurs again for that visitor's browser.

includeSubDomains and preload

includeSubDomains extends the same protection to every subdomain of the domain, not just the exact one that sent the header, which matters because a single unprotected subdomain can otherwise become a weak point. preload is a request to be added to a list built into browsers themselves, so that even a visitor's very first request to a domain, before it has ever received the header once, is already forced to HTTPS. Getting onto this list requires meeting stricter requirements and is a deliberate, largely irreversible commitment, since removal from the list can take months to take effect across everyone's browsers.

What to check before turning it on

HSTS is genuinely difficult to walk back quickly once a long max-age value has been set and seen by visitors, since their browsers will keep enforcing HTTPS for that domain regardless of what the server does afterward, until the value expires. Before setting a long duration, confirm every subdomain that needs to be reachable actually has a working, currently valid certificate, since includeSubDomains applies to all of them at once, including ones that might not be ready.

What HSTS does not do

HSTS says nothing about whether the certificate itself is trustworthy, correctly configured, or even present. It only controls whether a browser will attempt a plain HTTP connection at all. A domain can have HSTS enabled and still fail a certificate check entirely if the certificate itself has expired, which is why this is one part of a security setup rather than a replacement for checking the certificate separately.

Checking your own site

Run your domain through Security Headers to confirm HSTS is present, and through SSL Checker to confirm the certificate it depends on is actually valid. Together they cover both halves of what makes HTTPS reliably enforced rather than merely available.