TLS protects an HTTPS connection only after the client has chosen HTTPS and completed the TLS handshake. That leaves a separate problem at the scheme boundary. A user can enter a bare hostname, follow an old http:// link, or reach a redirect that starts in cleartext. An attacker able to interfere with that first HTTP exchange can try to keep the browser away from HTTPS.
HTTP Strict Transport Security (HSTS), defined by RFC 6797, moves that decision into the user agent. After a host sends a valid Strict-Transport-Security header over a secure connection, a conforming user agent records the policy. During its lifetime, later attempts to contact that host with HTTP are converted to HTTPS before an HTTP request is sent.
HSTS does not make TLS stronger. It changes when HTTPS becomes mandatory and how the client handles failures.
The policy arrives over HTTPS
A server can send a header such as:
Strict-Transport-Security: max-age=31536000; includeSubDomainsmax-age is the policy lifetime in seconds. includeSubDomains extends the policy from the HSTS host to its subdomains.
The transport used to receive the header matters. A user agent must not accept an HSTS policy delivered over insecure HTTP. Otherwise, an active attacker on that HTTP path could create or alter security policy. The policy is therefore established through an authenticated HTTPS connection.
A response can remove a previously stored policy by sending max-age=0 over a secure connection. That removal does not necessarily erase protection inherited from an HSTS ancestor that used includeSubDomains.
HTTP navigation is rewritten locally
Once a host is known as an HSTS host, the user agent treats an HTTP URI for that host differently. It changes the scheme to HTTPS before making the network request covered by the policy. For the usual HTTP port 80, the URI is mapped to HTTPS on port 443; an explicitly specified non-80 port is retained while the scheme changes.
That local rewrite closes a gap left by server-side redirects. A conventional pattern such as:
http://example.com/ -> 301 -> https://example.com/still requires an initial cleartext HTTP exchange. With an active HSTS policy, the browser does not depend on that redirect for covered navigation.
This distinction is central to HSTS. The protection comes from client state that exists before the next insecure request would leave the device.
Certificate errors become hard failures
HSTS also changes error handling for TLS. For an HSTS host, the user agent must terminate the connection when the TLS certificate is not trusted or presents another certificate error covered by the specification. It must not let the user bypass the error and continue to the site.
That behavior prevents HSTS from being reduced to an HTTPS preference with an exception button. A forced HTTPS connection paired with an overridable certificate warning would still permit a user to cross the authentication boundary manually.
The rule does not guarantee that every certificate accepted by the platform represents the operator a person expected. HSTS relies on the user agent’s certificate validation and trust model; it does not replace that model.
The first contact remains a boundary
A host cannot securely install its first HSTS policy through an HTTP response. If a user has never reached the site securely and no policy is already known, an attacker controlling that first HTTP exchange can attempt to suppress the redirect to HTTPS.
Browser preload lists address this bootstrap gap for participating sites by shipping HSTS-like knowledge with the browser rather than waiting for a header observed at runtime. Preloading is an ecosystem mechanism rather than part of the core RFC 6797 header processing model, and browser programs set their own submission and removal requirements.
For deployments that rely only on the response header, the first secure contact remains significant. After the policy is stored, its max-age determines how long the user agent can enforce it without receiving a fresh policy.
Subdomain coverage needs deliberate deployment
includeSubDomains is powerful because one policy can cover an entire subtree. It is also operationally strict. Every affected hostname that users may contact must be able to serve valid HTTPS for as long as the inherited policy applies.
Consider:
example.com
api.example.com
legacy.example.comIf example.com sets HSTS with includeSubDomains, an HTTP attempt to legacy.example.com is also subject to HTTPS enforcement. A legacy service that cannot complete valid TLS can become unreachable from conforming clients while that policy applies.
This is not a reason to avoid subdomain coverage; it is a reason to inventory the namespace before enabling it. Certificate issuance, TLS termination, forgotten hostnames, third-party services, and decommissioning plans all become part of the deployment boundary.
HSTS has a narrow job
HSTS does not encrypt DNS, authenticate application users, set cookie attributes, prevent cross-site scripting, or repair weak TLS configuration. It also does not protect arbitrary protocols that happen to use the same hostname.
Its job is narrower: once a user agent has a valid HSTS policy for a host, HTTP is no longer an acceptable route to that host during the policy lifetime, and TLS authentication failures are not user-overridable for the HSTS connection.
That narrow state machine is useful precisely because it removes a downgrade choice before an attacker can influence the next HTTP exchange.