HSTS Pins HTTPS Policy to the Browser

Redirecting HTTP traffic to HTTPS is useful, but a redirect is still an HTTP response. A browser that starts with http://example.com has already sent an unauthenticated request before the server can answer with 301 or 308. An attacker able to modify that connection can suppress or replace the redirect.

HTTP Strict Transport Security (HSTS) moves part of the transport policy into the browser. After receiving a valid Strict-Transport-Security header over HTTPS, a supporting browser remembers that the host requires secure transport for the declared lifetime. Later attempts to use HTTP for that host are upgraded locally before an HTTP request is sent.

The policy arrives only over HTTPS

A typical response header is:

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

max-age is measured in seconds. It tells the browser how long the HSTS policy remains active after receipt. Each valid HTTPS response carrying the header can refresh that lifetime.

Browsers ignore HSTS headers received over plain HTTP. Accepting policy from an unauthenticated channel would let a network attacker create or alter security policy. The server therefore needs a working HTTPS endpoint with a valid certificate before HSTS can establish browser state.

This creates an initial-contact gap. A browser with no stored policy can still begin with HTTP. HSTS protects subsequent visits after secure policy delivery; it does not retroactively secure the first unauthenticated request.

HTTP navigation is rewritten before transmission

While the policy is active, a browser treats an HTTP URL for the HSTS host as requiring HTTPS. Conceptually:

requested:
http://example.com/account

browser policy:
example.com -> HSTS active

network request:
https://example.com/account

The important boundary is where the change happens. A server-side redirect requires an HTTP round trip. HSTS causes the user agent to select secure transport before that insecure request leaves the browser.

Applications should still keep HTTP-to-HTTPS redirects. Clients without HSTS support, first visits without stored state, and operational tooling may still reach the HTTP listener. The redirect and HSTS serve related but distinct roles.

Certificate failures become hard failures

HSTS also changes error handling for TLS authentication. For an HSTS host, a browser must not offer the normal path that lets a user bypass an invalid certificate warning and continue.

That behavior matters because transport security depends on both encryption and authenticated endpoint identity. Silently falling back to HTTP or permitting a click-through around a certificate error would weaken the policy precisely when the secure connection cannot be authenticated.

Operationally, HSTS raises the cost of certificate mistakes. Expired certificates, hostname mismatches, or an incomplete deployment can make the site inaccessible to browsers that have stored the policy. Certificate renewal and deployment therefore need to be reliable before a long max-age is chosen.

includeSubDomains expands the policy boundary

The includeSubDomains directive applies the policy to subdomains beneath the HSTS host. If example.com sends:

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

the browser also treats hosts such as api.example.com and old.example.com as HSTS-covered while the parent policy is active.

This is powerful only when every relevant subdomain can support HTTPS correctly. A forgotten legacy host that still depends on HTTP can become unreachable after the parent policy expands to it.

Teams should inventory delegated, legacy, and externally hosted subdomains before enabling includeSubDomains. DNS ownership alone is not enough; each covered hostname needs a usable HTTPS path and certificate configuration.

Preloading addresses the initial-contact gap

Major browsers can ship with an HSTS preload list. A host on that list is treated as HSTS before the browser has received the site’s header, removing the ordinary first-visit HTTP gap for browsers carrying the entry.

Preloading is a stronger operational commitment than sending a response header. Removal is not instantaneous because browser releases and preload data take time to propagate. A domain intended for preload must be prepared to keep HTTPS available across the covered namespace according to the preload program’s requirements.

The response header remains relevant even for a preloaded domain. It expresses the live site policy and can refresh state independently of the browser’s bundled list.

HSTS does not replace application security controls

HSTS constrains transport selection in supporting user agents. It does not authorize requests, validate application input, prevent cross-site scripting, set cookie scope, or replace CSRF defenses.

It also does not make a compromised origin trustworthy. If an attacker controls the application server or obtains a certificate accepted for the hostname, HSTS does not distinguish that endpoint from the expected service. Its boundary is narrower: prevent HTTP downgrade for a remembered host and require valid TLS authentication without user bypass.

Session cookies should still use Secure where appropriate. HSTS can prevent browsers from sending an HTTP request to the covered host, while the cookie attribute separately tells the browser not to send that cookie over insecure transport.

Rollout should match the ability to recover

A cautious deployment often starts with a shorter max-age, confirms HTTPS behavior across the intended host set, then increases the lifetime. includeSubDomains and preload enrollment should come only after their broader consequences have been checked.

Monitoring should cover certificate expiry, TLS configuration, HTTPS reachability, and subdomain inventory. A long-lived browser policy turns an HTTPS outage from a warning into a hard access failure, so transport reliability becomes part of the security control.

HSTS is effective because the browser remembers a decision that the network cannot safely make on each visit. Once established, the policy removes HTTP from the normal connection path for that host and makes TLS authentication failure terminal instead of optional.