What is HSTS?

HSTS (HTTP Strict Transport Security) is a response header that tells browsers to refuse plain HTTP for your domain: every future request is upgraded to HTTPS before it leaves the browser, for as long as the header’s max-age lasts. It closes the gap that a redirect cannot — with only a redirect, each visit still starts with one insecure HTTP request that a network attacker can intercept and never let reach the redirect.

The header is a one-liner with three decisions in it. max-age says how long, in seconds, the browser should remember; common practice starts small and grows to a year or two once you trust your HTTPS setup. includeSubDomains extends the rule to every subdomain, which is where caution starts — it covers subdomains that do not exist yet and internal ones you forgot serve HTTP. preload opts you into the list compiled at hstspreload.org and shipped inside browsers, which removes even the first-ever insecure request; submission requires a max-age of at least one year plus includeSubDomains, and getting off the list again takes months.

The sharp edge is that HSTS removes the user’s escape hatch on purpose. For a domain the browser knows as HSTS, certificate errors cannot be clicked through — the "proceed anyway" option is gone. That is exactly the protection intended against attackers presenting fake certificates, and it means your own certificate mistakes graduate from warning to outage: an expired certificate or a subdomain served with the wrong certificate is a hard block for every returning visitor until you fix it.

The deployment order that avoids self-harm: get every hostname — including subdomains — serving valid HTTPS first, add HSTS with a short max-age, lengthen it as confidence grows, and only then consider includeSubDomains and preload. Preloading a domain whose certificate monitoring is an afterthought is how HSTS war stories start.