HSTS (HTTP Strict Transport Security)

HSTS is an HTTP response header that tells browsers to only connect to your domain over HTTPS. Once a browser receives a valid HSTS header, it will refuse to make any plaintext HTTP connections to that domain for the specified duration.

How HSTS Works

When a browser receives a response containing the Strict-Transport-Security header over a valid HTTPS connection, it stores the directive and applies it to all future requests. Any attempt to load the site over HTTP will be internally redirected to HTTPS before the request ever leaves the browser. This prevents SSL stripping attacks, where an attacker intercepts the initial HTTP request and downgrades the connection.

The header is only honored when delivered over HTTPS. Browsers ignore it on plaintext HTTP responses because an attacker could have injected or modified the header.

Header Syntax

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

• max-age - the number of seconds the browser should remember to enforce HTTPS. 31536000 is one year. Start with a short value (e.g., 300) during testing, then increase to at least one year for production.
• includeSubDomains - applies the HSTS policy to all subdomains of the current domain. Required for preload list submission.
• preload - signals that you want the domain added to the browser's built-in HSTS preload list. This is not an official part of the HTTP spec but is recognized by all major browsers.

HSTS Preloading

Even with HSTS, the very first visit to a domain is vulnerable because the browser has not yet received the header. The HSTS preload list solves this by hardcoding HSTS-enabled domains directly into the browser. Once your domain is on the preload list, browsers enforce HTTPS from the first connection, with no trust-on-first-use gap.

Requirements for preload list submission:

• Serve a valid HTTPS certificate on the base domain.
• Redirect all HTTP requests to HTTPS on the same host.
• Set max-age to at least 31536000 (one year).
• Include the includeSubDomains directive.
• Include the preload directive.

When NOT to Use HSTS Preloading

Preloading is difficult to reverse. Removal from the preload list can take months and requires a new browser release to reach users. Do not preload if:

• You have subdomains that cannot serve HTTPS - because includeSubDomains is required, every subdomain (including internal ones) must support HTTPS before preloading.
• You may need to temporarily revert to HTTP - once preloaded, there is no quick way to undo it. If your certificate provisioning breaks, users will be locked out.
• You use the domain for non-web services - HSTS affects all browser traffic, which can interfere with local development or internal tooling that shares the domain.

Common Mistakes

• Setting max-age too low - a value of 0 effectively disables HSTS. Use at least 31536000 (one year) for production. Short values only make sense during initial rollout and testing.
• Forgetting includeSubDomains - without this, attackers can set cookies on unprotected subdomains and use them to interfere with the parent domain (cookie injection attacks).
• Deploying HSTS before all subdomains support HTTPS - if you add includeSubDomains while some subdomains still run on HTTP, those subdomains will become unreachable in browsers.
• Sending HSTS over HTTP - browsers ignore the header on plaintext connections, so your HSTS configuration has no effect until the user first reaches you over HTTPS.

Audit your HSTS header with the headers tool →