What Is HSTS? HTTP Strict Transport Security Explained

HSTS (HTTP Strict Transport Security) is a response header, Strict-Transport-Security, that tells a browser to contact a hostname only over HTTPS for a set number of seconds. Once cached, the browser rewrites every http:// request to https:// locally and refuses to let users click through certificate errors, closing the window for SSL-stripping downgrade attacks.

HTTP Strict Transport Security is defined in RFC 6797, published in 2012, and its max-age directive is measured in seconds, so max-age=31536000 pins a host to HTTPS for one year. As of 2026, the HSTS preload list shipped inside Chrome, Firefox, Safari and Edge requires that one-year minimum plus includeSubDomains and preload before a domain is accepted.

How the Strict-Transport-Security header works in the browser

The browser stores an HSTS policy only when the header arrives over a valid HTTPS connection with no certificate errors. The same header on a plain HTTP response is ignored by design, because an attacker on the path could forge or strip it. Policies attach to hostnames, never IP addresses, and apply regardless of port.

After the policy is stored, three behaviors change for the life of max-age:

• Local upgrade. Typed URLs, bookmarks and http:// links are rewritten to https:// before any packet leaves the machine. Chromium surfaces this in DevTools as a 307 Internal Redirect that never touched the network.
• Hard-fail TLS. Expired, mismatched or self-signed certificates produce an error page with no bypass button.
• Sliding expiry. Every HTTPS response carrying the header resets the countdown, so an active user effectively never expires.

The weak spot is trust on first use. A browser that has never seen the host, or whose policy expired, still sends its first request over HTTP, and an attacker on that hop can keep the session in cleartext. Preloading closes that gap.

What max-age, includeSubDomains and preload actually control

max-age sets the policy lifetime in seconds. A value of 0 tells the browser to delete its stored policy, which is the only remote kill switch you have, and it only reaches browsers that come back over HTTPS.

includeSubDomains extends the policy to every descendant hostname. Set on example.com, it covers www, api, cdn, and also forgotten hosts like an HTTP-only printer admin page or a staging box with a self-signed certificate.

preload is not part of RFC 6797. It is a consent token telling the preload list maintainers that the domain owner wants the policy compiled into browser binaries.

What is HSTS preload and when should you submit?

HSTS preload is a list of domains hardcoded into browser source code, so HTTPS is enforced on the very first visit with no prior header seen. Submit only after every subdomain has served valid HTTPS for weeks, because removal requires a new browser release cycle and stale installed versions keep enforcing the entry for months.

As of 2026 the submission criteria are: a valid certificate, an HTTP to HTTPS redirect on the same host before any cross-host redirect, HTTPS on all subdomains, and a header on the apex with max-age of at least 31536000, includeSubDomains and preload. Preloading a whole TLD-style namespace you do not fully control is how teams lock themselves out.

A safe HSTS rollout ladder with blast radius

The useful way to pick max-age is to treat it as worst-case lockout time: if a hostname breaks HTTPS tomorrow, returning visitors cannot reach it until their stored policy expires or you fix TLS.

Each step multiplies your exposure to a TLS mistake, so the exit criterion of the previous stage matters more than the value you move to.

The production header then reads:

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

In nginx this is an add_header directive with the always parameter. Without always, nginx emits the header only on 2xx and 3xx responses, so error pages silently miss it.

How to deploy HSTS behind a CDN

Behind a CDN, the browser sees the edge, not your origin, so the edge certificate and the edge response headers are what define your HSTS posture. Decide in one place who emits the header, then verify it on every path the edge can answer from.

• Pick one emitter. If both origin and edge add the header, the browser processes only the first one, per RFC 6797. Two configs drifting apart means your effective max-age is whichever happens to arrive first.
• Cover edge-generated responses. Redirects, cache-miss errors and purge-time 503s produced by the CDN never reach origin config. If the origin is the emitter, these responses carry no policy.
• Check cached objects. Shortening max-age at origin does nothing for objects cached with the old header until they expire or are purged.
• Redirect order. The plain HTTP request must redirect to HTTPS on the same hostname first; a header attached to that HTTP redirect is ignored anyway.
• Certificate coverage is now availability. With includeSubDomains, an expired edge certificate on cdn.example.com is a hard outage with no click-through.

For CDN-fronted static hostnames, BlazingCDN includes HTTPS and SSL certificates for custom domains on every plan and serves TLS 1.3, and because zones are set up together with an engineer, that onboarding call is the right moment to agree on which layer emits the header. The BlazingCDN HTTPS and delivery features list what is included per zone.

HSTS vs. redirects, CSP and HPKP

HSTS vs. a 301 redirect to HTTPS: the redirect happens on the network after a cleartext request, so an attacker can intercept it. HSTS removes that cleartext request for returning visitors, and preload removes it for first visits. You need both: preload requires the redirect.

HSTS vs. CSP upgrade-insecure-requests: the Content Security Policy directive rewrites subresource URLs inside one page to HTTPS, fixing mixed content. It does nothing for top-level navigation or certificate errors, and it is not remembered across visits.

HSTS vs. HPKP: HTTP Public Key Pinning pinned specific keys rather than the scheme, and browsers removed it after misconfigurations bricked sites. HSTS only pins "use HTTPS with any valid certificate", which is why it survived.

Common HSTS misconceptions

"Setting the header on HTTP turns it on." It does not; browsers ignore Strict-Transport-Security on cleartext responses.

"max-age=0 removes us from preload." It clears stored dynamic policies only. Leaving the preload list needs a removal request and then waiting for updated browser builds to reach users.

"HSTS encrypts traffic." It enforces the scheme. TLS configuration, cipher choice and certificate hygiene remain separate work.

FAQ: HSTS and HSTS preload

What is HSTS used for?

HSTS is used to force browsers onto HTTPS for a hostname and block SSL-stripping downgrade attacks. After a browser receives the Strict-Transport-Security header over valid HTTPS, it rewrites all http:// requests locally and disables certificate warning bypass. It protects returning visitors by default, and first-time visitors only when the domain is on the browser preload list.

What max-age should I use for HSTS?

Use 31536000 seconds (one year) or 63072000 (two years) in production, but only after ramping up. Start around 300 seconds, move to one day with includeSubDomains, then 30 days through a full certificate renewal. The max-age value equals your worst-case lockout if any covered hostname breaks HTTPS, so raise it only once monitoring is in place.

How do I remove a domain from the HSTS preload list?

Removing a domain from the HSTS preload list requires a removal request to the list maintainers, then waiting for browser releases that ship the updated list. Users on older builds keep enforcing HTTPS for months. Also serve max-age=0 to clear dynamic policies, and drop the preload token so the domain is not automatically re-added.

Does HSTS work behind a CDN?

Yes, HSTS works behind a CDN, but the browser trusts what the edge returns. The edge certificate must be valid for every covered hostname, and the header must appear on edge-generated responses such as redirects and errors. Emit it from one layer only, since RFC 6797 tells browsers to process just the first Strict-Transport-Security header received.

Audit your HSTS coverage before raising max-age

This week, export every hostname under your apex from DNS and certificate transparency logs, then request each over HTTPS and record three things: whether Strict-Transport-Security appears on a 200, a 404 and a redirect; whether the header appears once or twice; and days until certificate expiry. Any hostname without valid HTTPS blocks includeSubDomains, and any certificate without an expiry alert blocks a one-year max-age. That spreadsheet is your preload readiness check, whatever CDN you run.

If your static, video or download hostnames are part of that inventory, the BlazingCDN Anycast CDN with TLS 1.3 and certificates included page describes how those zones are delivered and set up with an engineer in about an hour.