HSTS Explained: forcing browsers to always use HTTPS

You've done the right thing: your site is on HTTPS, and you redirect any http:// request to https://. Job done? Almost. There's a sliver of a gap — that very first insecure request before the redirect — and attackers can exploit it. HSTS is the header that closes it.

The gap HSTS closes

Even with an HTTP-to-HTTPS redirect, the sequence has a weak moment:

A user types example.com (browsers default to http://).
That first request goes out over plain HTTP.
Your server responds with a redirect to HTTPS.

Steps 1–2 happen unencrypted. An attacker on the network could intercept that first request and hijack it (an "SSL stripping" attack) before the redirect ever lands. The window is small, but it's real.

What HSTS does

HSTS (HTTP Strict Transport Security) is a response header that tells the browser: "For this site, always use HTTPS — never even attempt HTTP, no matter what."

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

Once a browser sees this, it remembers (for the max-age duration) to automatically convert any http:// request for your site to https:// before sending it — eliminating that insecure first request entirely.

The directives

Directive	Meaning
`max-age`	How long (seconds) the browser enforces HTTPS-only
`includeSubDomains`	Apply it to all subdomains too
`preload`	Opt into the browser preload list (HTTPS from the very first visit)

The preload list — powerful but careful

There's one more level: the HSTS preload list, baked directly into browsers. Sites on it are forced to HTTPS even on the very first visit ever, with no insecure request at all.

Preload is a commitment, not a setting. Once your domain is on the preload list, browsers will refuse HTTP entirely — and getting off the list is slow. Only preload when you're certain every subdomain can do HTTPS, forever. It's powerful, but hard to reverse.

How to deploy HSTS safely

Because HSTS is "sticky" (browsers remember it), a mistake is hard to undo. Roll it out gradually:

Make sure HTTPS works everywhere first — every page, every subdomain, valid certificates.
Start with a short max-age (e.g. a few minutes/hours) to test.
Increase max-age to a long value (a year is common) once confident.
Add includeSubDomains only when all subdomains support HTTPS.
Consider preload last, and only if you're fully committed.

The danger: if you enable includeSubDomains but a subdomain can't do HTTPS, browsers will refuse to load it — and they'll keep refusing until max-age expires.

A monitoring note

HSTS only helps if HTTPS keeps working. If your certificate expires while HSTS is active, browsers won't fall back to HTTP — they'll just block the site entirely, with no escape hatch. That makes certificate monitoring doubly important once HSTS is on.

The bottom line

	In one line
What	A header telling browsers to always use HTTPS for your site.
Why	Closes the insecure-first-request gap (SSL stripping).
Careful with	`includeSubDomains` and `preload` — hard to reverse.
Pair with	Rock-solid HTTPS + certificate monitoring (no fallback once on).

HSTS is a small header with a big security payoff — it makes "always HTTPS" truly always. Just deploy it gradually and keep your certificates healthy, because once HSTS is on, there's no falling back.