HTTP Strict Transport Security Pins HTTPS for Future Visits

TLS protects an HTTP connection only after the client is using HTTPS. A user who enters a bare hostname, follows an old http:// link, or reaches a redirecting HTTP endpoint can still begin with an unencrypted request.

HTTP Strict Transport Security (HSTS) gives a supporting browser a persistent rule for that host. After receiving a valid Strict-Transport-Security header over HTTPS, the browser records the policy and rewrites later HTTP navigation to HTTPS while the policy remains active.

The control is deliberately narrow. HSTS does not configure TLS on the server, repair certificate errors, or authenticate application users. It changes browser transport behavior so a stored host policy does not fall back to ordinary HTTP.

The policy arrives only over HTTPS

A typical response header is:

Strict-Transport-Security: max-age=31536000

max-age is measured in seconds. It tells the browser how long the host should remain an HSTS host from the time the policy is received.

A browser ignores an HSTS header delivered over plain HTTP. Accepting transport policy from an unauthenticated HTTP response would let a network attacker alter or inject that policy before TLS had protected the exchange.

This also creates the central bootstrap limitation. On a browser with no stored HSTS state, the first HTTP request can still cross the network before an HTTP-to-HTTPS redirect is processed. HSTS protects subsequent requests after a valid HTTPS response has established the state.

Stored HSTS state changes request handling

Once a host is known as an HSTS host, a supporting browser treats an http:// URL for that host as an HTTPS request before sending the insecure request. The upgrade happens in the user agent rather than as a server-side redirect.

That distinction removes an HTTP round trip and, more importantly, avoids exposing that request to manipulation on the cleartext path. An attacker on the network cannot rely on suppressing or rewriting an HTTP redirect when the browser already has active HSTS state.

HSTS also changes certificate-error handling. For an HSTS host, user agents do not provide the normal option to bypass TLS certificate errors and continue to the site. A broken or untrusted certificate therefore becomes an availability failure until the TLS configuration is corrected or the HSTS state no longer applies.

includeSubDomains extends the boundary

A host can extend its policy to subdomains:

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

With includeSubDomains, the policy applies to the host and names beneath it. A policy on example.com can therefore affect api.example.com, static.example.com, and deeper descendants.

This is useful only when the entire covered namespace is ready for HTTPS. A forgotten legacy host, development endpoint, or third-party service beneath the domain can become unreachable in browsers once the parent policy covers it and that endpoint cannot complete valid TLS.

The flag should be treated as a namespace commitment, not as a cosmetic hardening switch. Inventorying delegated zones, service aliases, old hostnames, and externally managed subdomains is part of a safe rollout.

Long max-age values create durable client state

HSTS state persists in the browser for the advertised lifetime. Each valid HTTPS response carrying the header can refresh that lifetime.

A short initial value is useful during deployment because mistakes expire sooner. Operators can increase the value after confirming that redirects, certificates, renewal automation, subdomains, and recovery procedures behave as intended.

Removing the header does not immediately erase policy already stored by clients. A site can send:

Strict-Transport-Security: max-age=0

over HTTPS to tell a supporting browser to remove the host’s HSTS policy. That response still has to reach clients successfully, and inherited policy from a parent using includeSubDomains can continue to cover the hostname.

The operational consequence is simple: HSTS duration should match the team’s confidence in sustained HTTPS operation. A one-year value is not merely a header setting; it is client state that can outlive a deployment rollback.

Preloading addresses the first-visit gap with a stronger commitment

Major browsers can ship an HSTS preload list containing selected domains. A browser that includes a domain in its built-in list can apply HTTPS-only behavior before that browser has ever visited the site.

Preloading closes the ordinary first-visit gap for browsers carrying the relevant list, but it adds operational commitment. Inclusion and removal follow browser preload program rules and release cycles; removing a header from a server does not instantly remove a domain from browser binaries already in circulation.

A domain considered for preload should already have stable HTTPS across the required namespace and satisfy the current preload program requirements. Preload status should not be used as a substitute for certificate renewal, TLS monitoring, or service inventory.

HSTS and redirects solve different parts of the transition

An HTTP redirect remains useful for clients without HSTS state and for non-browser clients that do not implement HSTS. It tells a client that reaches the HTTP service to request an HTTPS URL.

HSTS acts earlier for supporting browsers with stored state. The browser upgrades the URL before an insecure request is sent.

Deployments commonly retain an HTTP listener whose only purpose is redirection while also serving HSTS on HTTPS responses. The redirect handles bootstrap and compatibility cases; HSTS hardens later browser navigation.

The Strict-Transport-Security header belongs on HTTPS responses. Adding it only to the HTTP redirect does not establish HSTS state because browsers must ignore the header on insecure transport.

HSTS does not replace a valid TLS deployment

An HSTS host still needs a certificate that the browser accepts, a usable TLS configuration, and reachable HTTPS service. The policy makes failures in those components less bypassable; it does not make them less likely.

Certificate renewal deserves particular attention. If renewal fails and the certificate expires, users of an HSTS host cannot click through the resulting certificate warning. That is the intended security behavior, but it turns certificate operations into a direct availability dependency.

The same applies during migrations. Moving a hostname between providers, changing certificate authorities, or altering DNS should preserve valid HTTPS throughout the transition. A temporary HTTP fallback is incompatible with active HSTS state.

Scope is host based, not path based

HSTS cannot be limited to /login, /account, or another URL path. The browser records policy for a hostname, with optional coverage of subdomains.

This matters for sites that still mix secure and insecure applications on one host. HSTS is not a mechanism for protecting only the sensitive routes while leaving other paths on HTTP. The host needs to support HTTPS consistently.

Ports do not provide a general escape from the policy either. Browser HSTS processing upgrades applicable HTTP URLs according to user-agent rules; service architecture should not depend on an alternate HTTP port as a fallback for an HSTS hostname.

Rollout should preserve a recovery path

A cautious deployment starts with working HTTPS everywhere that the intended policy will cover. Certificate issuance and renewal should be automated or otherwise operated with enough margin to avoid expiry. Monitoring should test the HTTPS endpoint itself, not only whether an HTTP redirect returns a response.

The HSTS header can then begin with a modest max-age. After observing normal traffic, certificate renewals, and subdomain behavior, the duration can be raised. includeSubDomains deserves a separate review because it expands the failure domain.

Preload submission is a later decision. It should follow, rather than precede, a stable long-lived HTTPS posture.

HSTS is effective because the browser remembers a transport decision. That memory removes insecure downgrade opportunities after policy establishment, while making HTTPS availability and certificate correctness firm operational requirements for the covered hostnames.