HTTPS protects a connection only after the client has selected HTTPS and completed TLS. A user who enters a bare hostname, follows an http:// bookmark, or receives an HTTP link can still begin on cleartext HTTP before a server redirects the request. HTTP Strict Transport Security (HSTS), defined in RFC 6797, moves that redirect decision into the user agent after the origin has established a policy over a secure connection.
An HSTS policy is state held by the client. Once accepted, it changes future navigation and connection behavior for the covered host until the policy expires or is replaced.
The policy arrives only over secure HTTP
A server declares HSTS with the Strict-Transport-Security response header. A basic policy can look like this:
Strict-Transport-Security: max-age=31536000max-age is the number of seconds for which the user agent treats the host as a known HSTS host. A response received over insecure HTTP must not establish or refresh this state. Accepting the header over an unauthenticated channel would let an on-path party create policy state without first authenticating the server.
A policy can also cover subdomains:
Strict-Transport-Security: max-age=31536000; includeSubDomainsWith includeSubDomains, the policy applies to the host that sent it and to subordinate DNS names, subject to the processing rules in RFC 6797. Operators need to account for every affected service before enabling this directive on a parent domain.
Known HSTS hosts are rewritten before network access
For a known HSTS host, a conforming user agent transforms an insecure HTTP URI into a secure HTTPS URI before making the request. This is materially different from receiving an HTTP 301 or 308 redirect: the initial cleartext HTTP request is not sent to obtain the redirect.
The distinction closes a downgrade window after HSTS state exists. An active network attacker cannot simply suppress the server’s HTTP-to-HTTPS redirect, because the user agent no longer depends on that redirect for the covered host.
HSTS does not encrypt DNS by itself, authenticate arbitrary DNS answers, or replace TLS certificate validation. The eventual HTTPS connection still has to satisfy the user agent’s TLS authentication rules.
Certificate errors become hard failures
HSTS is intentionally strict when TLS authentication fails. For a known HSTS host, the user agent must terminate the connection on certificate errors covered by the specification rather than offering the ordinary option to continue past the warning.
This behavior matters because a bypassable certificate warning would weaken the policy. An attacker who could induce a certificate error could otherwise shift the user from an authenticated TLS connection into a manually accepted, unauthenticated state.
The policy does not make an invalid certificate valid. It changes failure handling: access is blocked instead of delegating the authentication exception to the user.
The first-contact gap remains
A host that has never supplied HSTS state to a particular user agent has no locally cached HSTS policy. If the user’s first contact begins with HTTP, an active on-path party can interfere before the browser receives a valid HSTS header over HTTPS.
This is the principal bootstrap limit of ordinary HSTS. The header protects subsequent contacts after secure policy acquisition; it cannot retroactively protect an earlier cleartext request.
Long max-age values reduce how often established state expires, but they do not eliminate first contact on a new client profile or device.
Preloading moves bootstrap state into the client
Browser vendors can ship an HSTS preload list containing domains that are treated as HSTS hosts before any network contact. Preloading addresses the bootstrap gap for included names because the client starts with policy state.
Preload programs are operational mechanisms rather than a new HSTS header directive defined by RFC 6797. Common browser preload processes impose their own submission and removal requirements. A site operator should treat preload enrollment as a durable deployment decision because removal can take time to propagate through browser releases.
The preload token is commonly sent in Strict-Transport-Security as a signal for preload ecosystems, but RFC 6797 does not assign that token HSTS processing semantics. User-agent preload behavior comes from browser policy and shipped data.
includeSubDomains expands the failure domain
A parent policy with includeSubDomains can secure a broad namespace, but it also makes HTTPS readiness across that namespace part of one operational boundary. A forgotten subdomain that only serves HTTP can become unreachable in a user agent carrying the parent HSTS state.
The same concern applies to internal or legacy names that are still reachable through public DNS under the covered parent. HSTS does not inspect organizational intent; the hostname relationship determines coverage.
A staged rollout can use a short max-age first, verify certificate issuance and HTTPS behavior across the intended namespace, then increase the duration. This reduces recovery time from an early configuration error, though it does not replace inventory and testing.
HSTS is not a content-security policy
HSTS acts on transport selection and TLS failure handling for covered hosts. It does not control script sources, frame ancestors, form destinations, or other document-level permissions. Those controls belong to mechanisms such as Content Security Policy.
It also does not force every embedded resource on the web to use HTTPS. Coverage follows HSTS host rules. A page can still reference another host that has no HSTS policy; separate browser security rules may affect that resource.
Keeping these boundaries explicit prevents HSTS from being credited with protections supplied by unrelated controls.
Policy lifetime is part of the security boundary
Every valid HSTS response can update the stored expiration time. A host can disable future HSTS state by sending max-age=0 over a secure connection, subject to user-agent processing and any separate preload status.
That escape path is useful during controlled decommissioning, but it also means certificate and HTTPS continuity matter throughout the policy lifetime. If a host is configured with a long policy and later loses the ability to present acceptable TLS, clients with active HSTS state cannot fall back to HTTP as a recovery path.
HSTS therefore converts HTTPS from a preferred transport into a client-enforced requirement for the covered period. Its value comes from that stateful commitment: after authenticated policy delivery, cleartext HTTP and user-bypassed certificate failures stop serving as fallback paths for the protected host.