HSTS Enforces HTTPS After a Host Policy Is Known

A redirect from HTTP to HTTPS moves a request onto TLS, but the first HTTP request still exists. If a browser starts with http://example.com, it can contact the HTTP endpoint before it receives the redirect. A network attacker positioned on that path can interfere before the browser reaches TLS.

HTTP Strict Transport Security (HSTS), standardized in RFC 6797, changes later navigation behavior. A conforming user agent that receives a valid Strict-Transport-Security response over secure transport records an HTTPS-only policy for the host. While that policy remains active, an HTTP URL for the host is rewritten to HTTPS before an insecure request is sent.

without cached HSTS:

http URL -> HTTP request -> redirect -> HTTPS

with active HSTS:

http URL -> local HTTPS rewrite -> HTTPS request

The security boundary is the browser’s retained policy. HSTS does not make HTTP encrypted and does not repair a compromised TLS endpoint. It removes an HTTP downgrade path once the user agent has reliable policy state.

The policy arrives over HTTPS

A server expresses HSTS with the Strict-Transport-Security response header:

Strict-Transport-Security: max-age=31536000

max-age is measured in seconds. Each accepted header refreshes the time for which the user agent treats the host as a known HSTS host. A value of zero tells the user agent to remove the stored policy for that host.

The header is meaningful only when received over secure transport. Accepting an HSTS policy from ordinary HTTP would let an on-path party create or alter policy before authentication. The secure delivery rule keeps policy establishment tied to an authenticated TLS connection.

This also means an HTTP redirect and HSTS perform different jobs. The redirect handles a request that already reached HTTP. HSTS affects future request construction inside the user agent.

Certificate errors remain hard failures

Once a host is known as HSTS, the browser does more than rewrite http to https. RFC 6797 requires connection termination when secure transport presents errors such as certificate validation failures; the user agent does not offer a path that lets the user continue past those errors for the HSTS host.

That property matters because an automatic HTTPS rewrite alone would still leave room for a user to click through a certificate warning. HSTS binds the remembered HTTPS-only decision to strict TLS error handling.

The mechanism does not alter certificate validation rules. Hostname checks, chain validation, validity periods, trust anchors, and other TLS policy still operate normally. HSTS changes the permitted fallback behavior around them.

includeSubDomains expands the boundary

A host can extend its policy to subordinate names:

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

With includeSubDomains, the policy applies to the host and its subdomains. Deploying it therefore requires an inventory of names below the domain. A forgotten HTTP-only service under that namespace can become unreachable in conforming browsers after the parent policy is active.

The scope is intentionally broad. It can protect names that have not yet established their own HSTS state, but the same breadth turns legacy subdomains into migration constraints.

Subdomains can also establish their own HSTS entries. Browser state for a subdomain may therefore outlive a parent entry or differ from it. Removing the parent policy with max-age=0 does not erase separately stored policies created by subdomains.

The first-contact gap remains

Ordinary HSTS is a trust-on-first-use mechanism for policy delivery. A new browser profile with no HSTS state can still begin at an HTTP URL. If the first secure response never arrives, the browser has no stored policy from that host to enforce.

new profile
   |
   v
no HSTS state
   |
   +--> HTTP can occur before first secure policy receipt

This limitation is separate from the strength of TLS used after HTTPS begins. Strong TLS configuration cannot cause a browser to possess an HSTS policy it has never received.

Preload lists address this bootstrap gap by shipping HTTPS-only knowledge with the browser rather than waiting for a live response. Preloading is an ecosystem mechanism rather than part of RFC 6797 itself.

Preloading is a deployment commitment

Sites seeking preload treatment commonly serve a header such as:

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

The preload token signals deployment intent to preload-list tooling; it is not the feature that causes RFC 6797 HSTS processing. Inclusion in a browser’s preload data is what supplies policy before first contact.

Preload programs impose their own submission requirements. Current browser ecosystem guidance commonly requires a long max-age and includeSubDomains. Those requirements can change independently of the HSTS standard, so deployment automation should treat preload eligibility as an external policy rather than hard-code it as protocol semantics.

Removal is also slower than sending a new header. A site can send max-age=0 to clients that reach it securely, but a preloaded entry remains present in browser releases until the preload data is updated and those releases reach users. That makes preload adoption unsuitable as a casual experiment.

Rollout should match the domain inventory

A staged rollout reduces the chance of making a required HTTP-only host inaccessible. A practical sequence is to establish reliable HTTPS on the target host, start with a modest max-age, observe operational behavior, extend the lifetime, and add includeSubDomains only after subordinate services are ready.

The exact values are deployment choices, not universal security constants. The important constraint is that policy duration creates a commitment. Once browsers cache a long lifetime, a server-side configuration rollback does not immediately clear client state.

Monitoring should cover certificate renewal, TLS reachability, redirect behavior for clients without HSTS state, and the set of subdomains covered by policy. HSTS can force clients toward HTTPS, but it cannot keep the HTTPS service healthy.

HSTS is most effective when treated as persistent client-side transport policy rather than as another redirect header. Its value comes from changing a browser’s behavior before an insecure request leaves the device, while its operational cost comes from the same persistence.