HSTS Enforces HTTPS After a Secure Origin Establishes Policy

HTTPS protects an HTTP exchange only after a secure connection is in use. A user can still type a bare hostname, follow an http:// link, or encounter an application that redirects HTTP to HTTPS. That initial HTTP request exists before an ordinary redirect can move the browser onto TLS.

HTTP Strict Transport Security (HSTS) moves the redirect decision into the user agent. A host sends the Strict-Transport-Security response header over HTTPS. Once the browser accepts that policy, later attempts to access the covered host with HTTP are rewritten to HTTPS before an insecure HTTP request is sent.

The policy arrives on a secure response

A typical header has a required max-age directive:

Strict-Transport-Security: max-age=31536000

max-age is expressed in seconds. It tells the browser how long the host remains a known HSTS host from the time the policy is received or refreshed.

The header is ignored when received over plain HTTP. Accepting HSTS policy from an unauthenticated HTTP response would let an on-path party create or alter transport policy before TLS had established the server identity.

A browser that already has an active HSTS policy does not rely on the server’s HTTP redirect for covered navigation. It upgrades the request locally and applies normal HTTPS certificate validation.

HSTS changes failure behavior

An HTTP-to-HTTPS redirect is an application response. If the first connection uses HTTP, an on-path attacker can interfere before that response reaches the browser.

HSTS removes that downgrade opportunity for a host whose policy is already known. It also changes certificate-error handling. For an HSTS host, the user agent must terminate the connection on TLS errors covered by the HSTS processing model rather than offering a path that lets the user continue through the certificate warning.

This property is deliberately strict. A site with an expired, mismatched, or otherwise unacceptable certificate can become inaccessible to clients that hold its HSTS policy until the TLS configuration is repaired or the applicable policy expires.

includeSubDomains expands the boundary

A host can extend HSTS to its subdomains:

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

With includeSubDomains, the policy applies to the host and subordinate hostnames. This is useful only when those names can all serve HTTPS correctly for the lifetime of the policy.

For example, setting HSTS on example.com with includeSubDomains affects names beneath that host. A forgotten legacy service on old.example.com that still depends on HTTP can stop working in browsers carrying the policy.

The directive therefore represents an operational commitment, not a cosmetic hardening flag. DNS inventory, certificate coverage, reverse proxies, third-party delegated hosts, and dormant subdomains all belong in the deployment review.

The first-contact gap still exists

A browser with no stored HSTS state can make an initial HTTP request. The server cannot retroactively protect a request that has already crossed the network in cleartext.

This is the first-contact limitation of dynamically delivered HSTS. Sites normally combine HSTS with an HTTP-to-HTTPS redirect so clients without stored policy are moved to HTTPS when that first HTTP exchange reaches the legitimate server.

After a valid HTTPS response establishes HSTS, subsequent covered requests gain the browser-side upgrade behavior until the policy expires or is replaced.

Preloading can remove the dynamic first-contact gap

Major browsers can ship an HSTS preload list. A host included in such a list is treated as an HSTS host before it has delivered a runtime header to that browser profile.

Preloading is a separate distribution mechanism rather than another meaning of the response header. Enrollment has operational requirements, and removal is not an immediate rollback across every installed browser. A domain should be ready to sustain HTTPS across the requested scope before treating preload as a deployment step.

The preload token commonly appears in headers for domains seeking preload status:

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

The token itself does not place a domain into browser preload lists. Inclusion depends on the preload program and browser distribution process.

Policy removal is intentionally delayed

A server can send:

Strict-Transport-Security: max-age=0

Over a valid HTTPS connection, this tells the user agent to remove the host’s dynamically stored HSTS policy. That does not guarantee immediate removal of policy inherited from a parent host through includeSubDomains, nor does it instantly remove a domain from browser preload data.

This distinction matters during rollback. HSTS state exists at the client, so changing server configuration alone does not erase policy already stored in browsers that have not yet received the new secure response.

Shorter max-age values are useful during an initial rollout because they bound the duration of mistakes. Once HTTPS coverage and certificate operations are stable, the lifetime can be increased deliberately.

HSTS is transport policy, not application authorization

HSTS constrains the scheme a browser uses for covered hosts. It does not authenticate application users, authorize requests, prevent cross-site request forgery, define content execution policy, or replace secure cookie attributes.

It also does not make a compromised HTTPS origin trustworthy. If an attacker legitimately controls the server endpoint or obtains control within the application’s trust boundary, forcing HTTPS does not repair that compromise.

The mechanism has a narrow role: once policy is established, prevent supporting browsers from choosing insecure HTTP for the covered host and make relevant TLS failures non-bypassable. Keeping that role precise makes deployment decisions clearer, especially when includeSubDomains and preload extend the duration and scope of the commitment.