← Glossary

Protocols & Acronyms

HSTS (HTTP Strict Transport Security)

Also: HTTP Strict Transport Security · Strict-Transport-Security · HSTS preload · STS header

Last reviewed:

In one sentence

HSTS is a response header (Strict-Transport-Security) that tells a browser to only ever reach your site over HTTPS for a set duration, so a later attempt to downgrade the connection to plain HTTP is refused by the browser itself.

Why it matters

Redirecting HTTP to HTTPS is not enough. The very first request — the one that gets redirected — travels in the clear, and that window is exactly where an attacker on the same network runs an SSL-stripping man-in-the-middle: they intercept the plain-HTTP request, keep HTTPS to your server, and read everything the user sends. HSTS closes that door by making the browser refuse HTTP for your domain outright, before a request ever leaves the machine.

It also upgrades a class of user mistakes into non-events. A user typing example.com (no scheme), clicking an old http:// bookmark, or hitting a mixed-content link — with HSTS active, the browser silently rewrites all of them to HTTPS. There is nothing to intercept because nothing insecure is ever attempted.

How the header works

Your server sends, over HTTPS, a header like:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age — how long (in seconds) the browser remembers to force HTTPS. Two years (63072000) is common; the preload minimum is one year (31536000).
  • includeSubDomains — apply the policy to every subdomain too, not just the exact host.
  • preload — your consent to be added to the browser preload list.

The header still has a bootstrap gap: a browser that has never visited you does not yet know the policy. Preloading fixes that — domains on the hardcoded list shipped inside Chrome, Firefox and Safari are forced to HTTPS even on the very first visit. To qualify (per hstspreload.org / Chromium) the base domain's HTTPS response must carry the header with max-age ≥ 31536000, includeSubDomains and preload, and port 80 must redirect to HTTPS on the same host first.

Try it yourself hands-on

Check whether a domain is actually preload-eligible — most sites that "have HSTS" are not.

  1. Open the CAA & HSTS Preload Checker and enter a domain. It fetches the base domain's first HTTPS response, parses the Strict-Transport-Security header, and lists any preload-eligibility issues in plain language — e.g. "max-age must be at least 31536000 (1 year)" or "preload directive is required".
  2. Note the two subtle failures the checker calls out specifically: if the base domain's first HTTPS response is a redirect that carries no HSTS header, preload fails (the header must be on the domain itself, not only the redirect target); and if http://domain/ redirects somewhere other than https://domain/ on the same host, that fails too.
  3. See HSTS in the context of your other security headers with the HTTP Security Headers Grader — it grades HSTS alongside CSP and the rest so you fix the whole header set at once.
  4. Because HSTS only makes sense with a valid certificate, confirm the TLS side with the SSL Certificate Checker before you commit to a long max-age.

Result: a concrete pass/fail on preload eligibility and the exact directive to change, instead of "I set the header, I think we're good".

Common misreadings

  • Preloading is hard to undo. Once you are on the hardcoded list, removal ships in a future browser release — months away. Do not add preload until every subdomain can genuinely serve HTTPS forever.
  • includeSubDomains is a commitment for the whole zone. An internal http://-only subdomain will simply break for users once it is covered. Inventory first.
  • HSTS needs a good cert. With a long max-age, a later certificate error becomes an un-clickable hard failure — users cannot bypass it. That is the intended behaviour, so keep renewals reliable.