HSTS Explained: Strict-Transport-Security

HSTS forces browsers to talk to your site over HTTPS only, and once a browser has seen the header it will not fall back to plain HTTP for the duration you specify. That closes the downgrade window an attacker uses to strip TLS and intercept traffic. The header is Strict-Transport-Security, and it belongs in the same baseline set described in HTTP security headers explained.

The problem it solves is concrete. A user types example.com without a scheme, the browser tries HTTP first, and a network attacker sitting in the middle can answer that request and keep the whole session on an unencrypted, manipulable connection. This SSL-stripping attack works precisely because the first hop is unprotected. HSTS instructs the browser to skip HTTP altogether on future visits. The behavior is specified in RFC 6797, and the OWASP Secure Headers project recommends concrete values for production use.

The directives

A complete header looks like this: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. There are only three parts, and most of the decision sits in max-age.

Directive	Purpose	Notes
max-age	Seconds the browser enforces HTTPS-only	Required; 63072000 is two years
includeSubDomains	Applies the rule to every subdomain	Every subdomain must already serve valid HTTPS
preload	Signals intent to join the browser preload list	Has no effect on its own; submit separately

max-age is a sliding window. Each time the browser receives the header, the clock resets, so an active site stays protected indefinitely. Set it to 0 to clear the policy, which is your escape hatch if something goes wrong.

The first-request gap and preload

Plain HSTS has one unavoidable weakness: the browser has to see the header at least once before it starts enforcing. The very first connection a new visitor makes is still vulnerable to stripping. The preload list closes that gap.

Browser vendors ship a built-in list of domains known to be HTTPS-only. If your domain is on it, the browser forces HTTPS from the first request, before any header is exchanged. You opt in by serving preload in the header and submitting your domain through the official preload submission process.

Treat preload as a commitment, not a toggle. Removal from the list is slow and may take many browser release cycles to propagate. You are promising that your domain and all its subdomains will serve valid HTTPS for the foreseeable future. Only submit once you are certain.

The risk: do not get ahead of your TLS

HSTS is unforgiving by design, and that cuts both ways. If you enable a long max-age while some subdomain, redirect, or certificate is still broken over HTTPS, browsers will refuse the HTTP fallback that would otherwise have rescued the user. They simply cannot reach the site, and you cannot fix it remotely because the policy lives in their browser until the timer expires.

The safe sequence:

1. Confirm every page and subdomain loads cleanly over HTTPS with a valid certificate.
2. Deploy a short max-age, such as 300 (five minutes), and watch for problems.
3. Raise it in stages, for example to one day, then one week.
4. Add includeSubDomains only after you have verified each subdomain.
5. Add preload and submit only when a long max-age has run trouble-free.

Relationship to TLS

HSTS does not encrypt anything itself; it is a policy layer on top of TLS. The certificate and protocol configuration still do the actual cryptographic work. What HSTS adds is the guarantee that the browser will always use that encrypted channel and never quietly accept a downgrade. Pair it with a modern TLS setup and you remove a whole class of interception attacks.

For how this fits with the rest of your defenses, see CSP explained, and to confirm what a live site is actually sending, read how to check security headers.

Curious whether a domain enforces HTTPS correctly and how long its max-age runs? Scan any site's headers free for an instant graded report.