HSTS Pins HTTPS Policy in the Browser

An HTTPS redirect does useful work only after an HTTP request reaches the server. That first cleartext request remains a weak point: a network attacker able to alter traffic can interfere before the browser receives the redirect.

HTTP Strict Transport Security, or HSTS, moves part of that decision into the browser. After receiving a valid Strict-Transport-Security header over HTTPS, a conforming user agent records a policy for the host. During the policy lifetime, later HTTP navigation to that host is rewritten to HTTPS before an HTTP connection is made.

https://example.test
        |
        v
Strict-Transport-Security: max-age=31536000
        |
        v
browser stores HSTS policy
        |
        v
http://example.test/path
        |
        v
https://example.test/path

The header does not make TLS certificates optional, repair certificate errors, or encrypt traffic that never reaches HTTPS. Its job is narrower: once policy is established, the browser no longer treats cleartext HTTP as an acceptable transport for that host.

The policy arrives only over HTTPS

A browser must ignore Strict-Transport-Security received over insecure HTTP. Accepting the header there would let an attacker inject long-lived transport policy for arbitrary hosts.

That rule creates the bootstrap gap. On a browser with no prior HSTS state, a user who types a bare hostname may still begin with HTTP. The server can redirect to HTTPS and then send HSTS, but an active attacker on that first path can interfere before the secure response establishes policy.

This distinction matters operationally:

first visit without cached policy:
HTTP -> redirect -> HTTPS -> HSTS stored

later visit while policy is active:
HTTP URL -> local HTTPS rewrite -> HTTPS

HSTS protects later connections after a trustworthy policy has been received. Preloading addresses the initial-contact case through a separate mechanism.

max-age defines the policy lifetime

The required directive is max-age, expressed in seconds:

Strict-Transport-Security: max-age=31536000

The browser records an expiry relative to the time it processes the secure response. A later valid HSTS response can refresh that lifetime.

A long value reduces the chance that policy expires between visits, but it also makes mistakes persistent. Before deploying a long lifetime, the host needs reliable HTTPS, valid certificates, and a recovery plan that does not depend on serving plain HTTP.

A server can request removal of a dynamic HSTS policy by sending this over HTTPS:

Strict-Transport-Security: max-age=0

That instruction still requires a successful HTTPS connection. If the host cannot complete TLS at all, plain HTTP cannot clear the policy.

includeSubDomains expands the boundary

Adding includeSubDomains applies the policy to subdomains as well as the host that emitted it:

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

For a policy set on example.test, this can cover hosts such as api.example.test and old.example.test. The scope is valuable only when every affected name that users may reach is prepared for HTTPS.

This is a deployment boundary, not a cosmetic directive. A forgotten subdomain that still depends on HTTP can become inaccessible in browsers enforcing the parent policy. Inventory, certificate coverage, DNS ownership, and legacy endpoints therefore belong in the rollout review before the directive is enabled at a parent domain.

A subdomain may also establish its own HSTS policy. Parent coverage and host-specific policy can coexist, with user-agent processing governed by the HSTS specification.

HSTS changes certificate-error handling

When HSTS applies, the user agent must terminate the connection on TLS errors covered by the policy rather than offer a click-through path that would bypass the warning.

That behavior is central to the mechanism. If a user could ignore a certificate error and continue, an active attacker could present an invalid certificate and rely on the user to defeat the transport rule manually.

It also raises the operational cost of certificate failures. Expired certificates, hostname mismatches, or broken trust chains can turn into hard failures for HSTS hosts. Certificate renewal and monitoring are therefore part of HSTS operations, not separate housekeeping.

Preload closes a different gap

Major browsers can ship an HSTS preload list. A domain accepted into that list is treated as HSTS before the browser has received the site’s own header.

Preloading can remove the first-visit bootstrap gap, but it is not simply a stronger header value. Inclusion and removal are browser-distribution processes with their own requirements and delay. A domain operator should treat preload as a commitment that HTTPS works across the required scope, especially when subdomains are included.

The preload token commonly appears in deployment headers:

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

The token by itself does not place a domain into browser preload lists. List inclusion depends on the relevant preload program and browser release process.

HSTS does not replace HTTPS redirects

HSTS-aware browsers can upgrade an HTTP URL locally, but servers should still handle HTTP appropriately. Not every client implements HSTS, cached policy can expire, and automated clients may follow different transport rules.

A redirect remains useful for clients that reach the HTTP endpoint. HSTS adds browser-side enforcement after policy establishment; it does not turn the HTTP listener into a security boundary.

The two controls therefore cover different moments:

HTTP redirect:
request reaches HTTP service -> server points client to HTTPS

active HSTS policy:
browser rewrites URL -> HTTP request is not sent

Rollout should narrow the failure surface first

A cautious rollout starts with working HTTPS and a modest max-age, then extends the lifetime after certificate renewal, redirects, subdomains, and monitoring have been exercised. includeSubDomains should follow only when the covered namespace is ready. Preload deserves a separate decision because rollback depends on list updates reaching browser releases.

HSTS is compact configuration with durable client-side state. Its security value comes from moving the HTTPS decision ahead of the network request, while its operational risk comes from the same property. A deployment is sound when the domain can sustain HTTPS for the full scope and lifetime it asks browsers to enforce.

References

Cybersecurity HTTPS HSTS Web Security