Strict-Transport-Security

Downgrade attacks strip HTTPS from connections, exposing traffic to interception. The Strict-Transport-Security response header prevents this by instructing browsers to access a site exclusively over HTTPS for a specified duration.

Baseline: Widely available

Supported across all major browsers. webstatus.dev

Table of Contents

Usage

The Strict-Transport-Security header is the mechanism behind HTTP Strict Transport Security (HSTS). When a browser receives this header over a secure connection, the browser records the directive and automatically upgrades all future HTTP requests to HTTPS for the specified domain. If the secure connection is unavailable, the browser refuses access entirely rather than falling back to plain HTTP.

This header is only respected when delivered over HTTPS. A response served over plain HTTP containing Strict-Transport-Security is ignored, because an attacker on the network path is able to inject or modify the header.

The header accepts three directives: max-age, includeSubDomains, and preload.

Directives

max-age

The max-age directive is required. The value specifies the number of seconds the browser remembers to enforce HTTPS for the domain. A common production value is 63072000 (two years). Setting max-age=0 immediately clears the HSTS entry from the browser cache.

includeSubDomains

The includeSubDomains directive extends the HTTPS enforcement to every subdomain of the host. Without this directive, HSTS applies only to the exact domain in the response. Adding includeSubDomains prevents an attacker from exploiting a plain-HTTP subdomain to set Cookies or redirect traffic.

preload

The preload directive is not part of the HSTS specification. Browser vendors maintain HSTS preload lists, and the preload directive signals the domain owner's intent to be included. Once a domain appears on a preload list, browsers enforce HTTPS from the first connection, eliminating the window of vulnerability before the first Strict-Transport-Security header is received. Submitting a domain to the preload list requires max-age of at least one year (31536000 seconds) and the includeSubDomains directive.

Example

A server enforcing HTTPS for two years across all subdomains, with preload eligibility:

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

A minimal configuration setting HSTS for six months on the primary domain only:

Strict-Transport-Security: max-age=15768000

Clearing the HSTS entry by resetting the max-age to zero, useful during migrations or testing:

Strict-Transport-Security: max-age=0

Troubleshooting

HSTS problems tend to surface as connection failures or redirect loops that persist even after server changes, because the browser caches the policy locally.

  1. Locked out after enabling HSTS with a long max-age. Once a browser records the HSTS policy, all requests upgrade to HTTPS automatically. Reverting to HTTP is not possible until the max-age expires or the user manually clears the HSTS entry. In Chrome, open chrome://net-internals/#hsts, enter the domain under "Delete domain security policies," and delete the entry. In Firefox, close the browser, edit SiteSecurityServiceState.txt in the profile folder, and remove the domain line.

  2. Subdomain breakage from includeSubDomains. Adding includeSubDomains forces HTTPS on every subdomain, including internal tools, staging servers, and legacy services that lack a valid certificate. Verify that every subdomain serves a trusted TLS certificate before enabling this directive. Remove includeSubDomains and redeploy the header with max-age=0 to clear cached entries if a subdomain breaks.

  3. Preload list removal taking months. The HSTS preload list is shipped with browser releases, so removal requires submitting a request at hstspreload.org, waiting for the next list update, and waiting for that update to reach users through browser version upgrades. This process takes several months. Treat preload as a long-term commitment and verify full HTTPS readiness before submitting.

  4. HSTS header sent over plain HTTP is ignored. Browsers discard the Strict-Transport-Security header when the response arrives over an unencrypted connection. The header takes effect only on HTTPS responses. Confirm the header is present on the HTTPS response by checking with: curl -sI https://example.re | grep -i strict.

  5. Mixed content errors after enabling HSTS. HSTS upgrades the page to HTTPS, but embedded resources still referencing http:// URLs trigger mixed content warnings or blocks. Audit all resource URLs (images, scripts, stylesheets, API endpoints) and update references to use https:// or protocol-relative paths. The CSP directive upgrade-insecure-requests handles this automatically for remaining hard-coded HTTP URLs.

  6. Certificate renewal failure causing total site lockout. An expired or invalid certificate on an HSTS-protected domain results in a hard failure with no user bypass. Browsers refuse to show the site or offer an "proceed anyway" option. Automate certificate renewal (Let's Encrypt certbot handles this with a cron job) and monitor certificate expiry dates. Set alerts for at least 14 days before expiration.

See also

Last updated: April 4, 2026