HSTS Pins HTTPS Policy to Hostnames

HTTPS protects an HTTP exchange after a secure connection has been established and authenticated. A separate problem appears before that point: a user can enter a bare hostname, follow an http:// link, or reach a redirecting HTTP endpoint before the browser has any transport policy for the site.

HTTP Strict Transport Security (HSTS) addresses that transition. An HTTPS server sends a Strict-Transport-Security response header, and a conforming user agent records a policy for the host. While that policy remains active, matching HTTP requests are converted to HTTPS before an insecure network request is sent.

HSTS is therefore state held by the user agent, not a TLS cipher setting and not a server-side redirect rule.

The policy arrives over authenticated HTTPS

A typical response contains:

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

max-age states, in seconds, how long the user agent should retain the policy from the time it receives the header. includeSubDomains extends the policy to subdomains under the HSTS host.

The header is accepted only when received over secure transport. A copy delivered over plain HTTP cannot establish or refresh HSTS state. Otherwise an on-path party able to alter an HTTP response could create transport policy on behalf of a site.

This produces a deliberate ordering:

authenticated HTTPS response
        |
        | Strict-Transport-Security
        v
stored HSTS policy
        |
        v
later HTTP navigation
        |
        v
HTTPS request before network transmission

The initial secure response matters because dynamic HSTS has no effect before the user agent has stored the policy.

Upgrade happens before the insecure request

An HTTP-to-HTTPS redirect and HSTS can produce a similar address in the browser, but their security boundaries differ.

With a redirect, the browser first sends an HTTP request and receives a response that points to an HTTPS URL. That first request crosses the network without TLS protection. A network attacker in a suitable position can interfere before the redirect reaches the browser.

With an active HSTS policy, the user agent rewrites the request to HTTPS internally. The insecure request is not sent merely to obtain a redirect.

A redirect remains useful for clients that do not have HSTS state and for ordinary canonicalization. It does not provide the same pre-request transport rule.

Certificate errors remain fatal under HSTS

HSTS does not make an invalid certificate valid. It strengthens the requirement to use authenticated HTTPS.

For an HSTS host, user agents following RFC 6797 terminate the connection when secure transport has errors, rather than offering a path that lets the user continue through the certificate problem. This matters because an override would weaken the stored transport policy at the point where authentication failed.

The policy also does not select a certificate authority, rotate certificates, or repair a broken certificate chain. Certificate issuance and TLS configuration remain separate operational responsibilities.

includeSubDomains changes the deployment boundary

Without includeSubDomains, policy for example.com applies to that host according to HSTS matching rules. Adding the directive extends the policy to subordinate DNS names.

That extension can be valuable when every subdomain is intended to support HTTPS, but it increases the blast radius of configuration mistakes. A forgotten service at legacy.example.com that only supports HTTP can become unreachable from a user agent holding the parent policy.

Teams should inventory subdomains before enabling a long-lived parent policy with includeSubDomains. The relevant set includes less visible endpoints such as internal portals exposed through public DNS, old campaign hosts, vendor integrations, and temporary service names.

A child host can also have its own HSTS policy. Policy lookup follows host matching rules rather than treating HSTS as one global browser switch.

Expiry and removal require time

A site can request removal of a dynamically stored policy by sending:

Strict-Transport-Security: max-age=0

That instruction also has to arrive over secure transport. It cannot help a client that can no longer establish the HTTPS connection needed to receive the new header.

This creates an operational asymmetry. Increasing max-age is easy once HTTPS works; recovering from a bad long-lived policy can be difficult when the HTTPS endpoint itself is broken.

For that reason, staged rollout is safer than immediately choosing a long duration. Operators can start with a short lifetime, verify certificate renewal and subdomain coverage, then increase the lifetime as the deployment proves stable.

Preloading closes the first-contact gap with a separate mechanism

Dynamic HSTS begins only after a user agent has received a valid HSTS header from the host. A fresh browser profile has no such state, so the first contact can still begin with HTTP.

Browser preload mechanisms address that gap by shipping a list of hosts that should be treated as HSTS before any visit. Preloading is not created by RFC 6797 alone; it is an ecosystem mechanism maintained by browser projects and has enrollment requirements outside the core HSTS protocol.

A site considering preload should treat it as a stronger operational commitment than sending the header dynamically. Removal is not instantaneous because deployed browser versions carry their own copies of preload data.

The preload token commonly placed in the header is associated with preload-list enrollment. It is not one of the directives defined by RFC 6797, and its presence by itself does not place a domain into browser preload lists.

HSTS is scoped to transport, not application security

HSTS blocks a specific class of transport downgrade for user agents that have applicable policy. It does not prevent cross-site scripting, request forgery, authorization defects, unsafe file handling, compromised application code, or credential theft outside the protected transport path.

It also cannot guarantee that every client implements HSTS. Non-browser HTTP stacks may ignore the header or implement their own policy. Service-to-service systems therefore need explicit TLS requirements in their clients rather than relying on a browser-oriented response header.

The useful invariant is narrower: once a supporting user agent has applicable HSTS state, HTTP is no longer an acceptable transport route for that hostname during the policy lifetime. Maintaining that invariant depends on reliable HTTPS, valid certificates, deliberate subdomain scope, and policy durations that match the operator’s ability to keep those properties intact.