· Development

What HSTS stops and what it doesn't: max-age, includeSubDomains, preload

What a browser does after receiving Strict-Transport-Security, per RFC 6797: the first-visit gap, the upside and risk of includeSubDomains, staged max-age, and why preload is no longer recommended.

DevelopmentSecurity

On some sites, clicking an http:// link never produces a plaintext request: the browser rewrites the address to https:// first. It does that because it remembers a Strict-Transport-Security response header the site sent earlier. That behavior is HSTS (HTTP Strict Transport Security), defined in RFC 6797.

Why a redirect is not enough

Even if the server sends you to HTTPS with a 301 redirect, the first request still goes out in plaintext. hstspreload.org describes the attacks that live at that point. An on-path attacker can intercept and rewrite the redirect to keep the browser on HTTP, can see and modify cookies on HTTP requests, and can inject cookies into the redirect response. A browser that holds an HSTS policy never sends that plaintext request at all.

What the browser does

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

max-age is required. It sets how many seconds after receiving the header the browser treats the host as a Known HSTS Host. includeSubDomains is optional and extends the policy to every subdomain. These are the only two directives RFC 6797 defines; a browser must ignore directives it does not recognize and process the rest.

The browser records the header only from a response received over a secure connection with no errors. It MUST ignore the header in an HTTP response, and the server MUST NOT put it in one. A value set through HTML <meta http-equiv> is not honored either, and a host reached by IP address is never recorded. If one response carries several of these headers, only the first is processed.

While the record is live, before loading any http URI for that host, including when following a redirect, the browser replaces the scheme with https. An explicit port 80 becomes 443; any other explicit port is kept. If the TLS connection has any error or warning, certificate validation failures included, the browser MUST terminate it. The RFC also advises not letting the user click through the warning, but that part is non-normative implementation advice.

If later responses leave the header out, the policy still lasts until max-age runs out. To delete it, send max-age=0 over HTTPS; any includeSubDomains alongside it is ignored.

The first visit is not protected

The browser has to connect once before it can receive the header. If a user types an http address for a host the browser has no policy for, or follows an http link to it, that first request goes out in plaintext. RFC 6797 calls this the bootstrap MITM vulnerability. Expired records are evicted, so the first connection after max-age has passed is in the same position.

One mitigation the RFC lists is a pre-loaded list built into the browser. Chrome maintains such a list through hstspreload.org, and other major browsers, including Firefox, Safari and Edge, have lists based on Chrome’s.

Both sides of includeSubDomains

RFC 6797 explains that without this directive, domain cookies with the Secure attribute cannot be protected. Suppose an attacker registers a subdomain under example.com that never existed, points it in DNS at their own server, and gets the browser to make a request there. That subdomain has no HSTS policy, so if the user clicks through a certificate warning, the cookie can reach the attacker.

The flip side: a subdomain that does not serve HTTPS properly becomes unreachable from any browser holding the policy. The RFC’s example is a certificate authority serving CRL and OCSP over plain HTTP. If ca.example.com sends includeSubDomains, that browser can no longer fetch certificate status from crl-and-ocsp.ca.example.com. hstspreload.org likewise says to check first that every subdomain works over HTTPS, including internal ones that are not publicly accessible.

Where the header is sent matters too. If only example.com sends it and users always arrive at www.example.com, a browser that has never contacted example.com never receives the policy. The RFC advises sending the header directly from every host that serves as an entry point (non-normative).

Raise max-age in stages

hstspreload.org’s deployment recommendation is to add the header to all HTTPS responses and, with includeSubDomains, raise max-age through 300 (5 minutes), 604800 (1 week) and 2592000 (1 month). At each stage you check for broken pages and watch metrics such as traffic, then wait out that stage’s full max-age before moving on. A browser that has the header keeps the policy until max-age ends or it receives max-age=0 over HTTPS, so starting short keeps the window affected by a mistake short. RFC 6797 also advises server configuration systems to default max-age to 0, so that operators cannot turn HSTS on without meaning to (non-normative).

hstspreload.org’s submission requirements are a valid certificate; a redirect from HTTP to HTTPS on the same host if you listen on port 80; HTTPS on all subdomains; and, on the base domain, a header with max-age of at least 31536000 seconds (1 year) plus includeSubDomains and preload. preload is not a directive defined in RFC 6797. It signals a request to be put on that list.

As checked on October 13, 2026, hstspreload.org states that HSTS is recommended but HSTS preloading is not. Many browsers, including Chrome and Safari, now upgrade HTTP navigations to HTTPS automatically regardless of a domain’s HSTS policy, so preloading only adds value when those upgrades fail in the presence of an active attacker. Getting off the list is not easy either: the site says a removal takes months to reach users through a Chrome update, and it makes no guarantees about other browsers. For that reason it asks HTTPS configuration tools and guides not to include preload by default.

Scope

RFC 6797 (2012) is a Standards Track document, and the MUST and MUST NOT requirements above are its normative rules. The server deployment advice (Section 11) and user agent implementation advice (Section 12) are sections the RFC itself marks non-normative. Staged max-age, the preload submission requirements and the position against preloading are policies of hstspreload.org, the submission site for Chrome’s pre-loaded list; they are not part of the standard and may change.

References

Back to the blog