What Is HSTS? HTTP Strict Transport Security Explained

HSTS (HTTP Strict Transport Security) is a response header that tells a browser to only ever connect to a given site over HTTPS — never plain HTTP — for a specified period of time. Once a browser has seen the header, it rewrites any future http:// request to that domain into https:// internally, before a single packet leaves the machine. It closes a specific gap that redirects alone can’t: the brief, unencrypted first request that happens before a redirect has a chance to run.

The gap HSTS closes

A typical site handles HTTP-to-HTTPS upgrades with a server-side redirect: a request to http://example.com gets a 301 pointing to https://example.com. That works, but the very first request — the one that triggers the redirect — still goes out over plain HTTP. An attacker positioned on the network (a malicious Wi-Fi hotspot, a compromised router) can intercept that initial request and simply never let the redirect happen, quietly serving the rest of the session over HTTP while presenting content that looks unchanged to the user. This is the core of an SSL-stripping attack, and it works precisely because the browser has no way of knowing, in advance, that it should have refused the HTTP connection outright.

HSTS fixes this by making the browser remember the requirement. After the first successful HTTPS visit, the browser enforces HTTPS-only on its own, without needing a redirect or a server round trip to prompt it.

The header

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

• max-age — how long, in seconds, the browser should remember to enforce HTTPS for this domain. A year (31536000) is a common value for production sites.
• includeSubDomains — extends the policy to every subdomain, not just the exact host that sent the header. Without it, mail.example.com wouldn’t be covered by a policy set on example.com.
• preload — opts the domain into browser preload lists, discussed below. This directive alone doesn’t do anything by itself; it just marks the site as a candidate for submission.

Because the header is delivered over HTTPS, it can only take effect after at least one successful HTTPS connection has already happened — which is the residual gap addressed by preloading.

Trust on first use, and its limit

HSTS by itself is a “trust on first use” mechanism: the very first request to a domain, before the browser has ever seen the header, still has no protection. If an attacker manages to intercept that exact first connection, they can strip HTTPS before the browser ever learns it should have refused to. For most users, most of the time, this window is small and low-risk — but it’s a real gap for high-value targets or first-time visitors on hostile networks.

Preload lists close that window

Browser vendors maintain a preload list: a hard-coded list of domains, shipped inside the browser itself, that are treated as HTTPS-only from the very first connection — no prior visit required. Getting a domain onto this list means submitting it (after already serving a valid preload HSTS header for a sustained period) to the list maintainers, who verify the site meets the requirements before including it in upcoming browser releases.

Because the list ships inside the browser binary, it isn’t something a network attacker can strip or forge — the browser already knows, before making any connection at all, that the domain must be reached over HTTPS.

HSTS vs redirects vs preloading

	HTTP→HTTPS redirect	HSTS header	Preload list
Protects the first request	No	No	Yes
Requires a prior visit	N/A	Yes	No
Enforced by	Server round trip	Browser, after first visit	Browser, from install
Removable by network attacker	Yes (redirect can be dropped)	No, once cached	No

Each layer covers a gap the previous one leaves open. Redirects handle the common case; HSTS protects every subsequent visit; preloading protects the very first one too.

Setting it up in practice

HSTS only makes sense once HTTPS is fully working across the entire site and all subdomains you intend to cover — enabling includeSubDomains on a domain with an HTTP-only subdomain will break that subdomain outright, since the browser will refuse to connect to it over HTTP once the policy is cached. A sensible rollout is to start with a short max-age, confirm nothing breaks, then raise it toward a year and add preload once you’re confident the policy is permanent. Because a cached policy is hard to undo — clients that already saw a long max-age will keep enforcing HTTPS until it expires, and a preload-listed domain requires an explicit removal request that takes browser release cycles to propagate — this isn’t a header to enable casually on a domain that might need to fall back to HTTP later.

HSTS is one layer in a broader transport-security setup. It works alongside a correctly configured TLS handshake and complements — but doesn’t replace — a Content Security Policy, which addresses a different class of attack (script and resource injection, not transport downgrade). If your site sits behind a WAF or CDN, confirm the header is added at the origin or edge consistently, since a missing header on even one path undermines the guarantee for the whole domain. For a broader look at how the underlying protocol get you to HTTPS in the first place, see our HTTPS explainer.

The takeaway

HSTS tells a browser to remember that a domain must only ever be reached over HTTPS, closing the window where a network attacker could intercept an unencrypted first request and quietly strip encryption for the rest of the session. The header alone still leaves the very first connection unprotected; the browser preload list closes that remaining gap by hard-coding HTTPS-only enforcement before any connection is made at all. Treat both as one-way commitments — verify HTTPS works everywhere covered by the policy before you set a long max-age or submit to preload.