HTTP Strict Transport Security

HSTS is a response header (Strict-Transport-Security) sent by a server to instruct the browser to only communicate over HTTPS for a specified period. The header includes a max-age directive (in seconds) and optional includeSubDomains and preload flags. Once received, the browser automatically upgrades any HTTP requests to HTTPS and refuses to proceed if the TLS certificate is invalid, mitigating man-in-the-middle attacks such as SSL stripping.

The mechanism was introduced to address the vulnerability where users type URLs without the scheme, allowing attackers to intercept the initial HTTP request. By preloading HSTS in browsers (via the HSTS preload list), even the first connection is secured. The preload list is maintained by Google and submitted through hstspreload.org.

To deploy HSTS, a server must have a valid TLS certificate and send the header on all HTTPS responses. The max-age should be set to a large value (e.g., 31536000 for one year) after testing with a short duration. The includeSubDomains directive extends the policy to all subdomains, but it must be used carefully to avoid locking out subdomains that do not support HTTPS.

For preloading, the site must meet strict criteria: a valid certificate, redirect from HTTP to HTTPS, and serve the HSTS header on all subdomains. Once added to the preload list, removal is difficult, so administrators must ensure long-term HTTPS support. Tools like securityheaders.com help assess HSTS implementation.

HSTS is effective only when the browser has received the header at least once; the first request remains vulnerable unless the site is preloaded. Additionally, HSTS does not protect against DNS rebinding or attacks that occur before the header is received. It also does not prevent the use of insecure cookies if they are set without the Secure flag.

Another limitation is that HSTS can be bypassed if the user manually accepts a certificate error, though browsers display strong warnings. In enterprise environments, HSTS may cause issues with legacy systems that rely on HTTP. Furthermore, the preload directive is not part of the original RFC but is a de facto standard supported by major browsers.

HSTS was originally proposed by Collin Jackson and Adam Barth in 2008, and it was later standardized in RFC 6797 in 2012. The specification includes a lesser-known directive, includeSubDomains, which can be dangerous if a subdomain is not HTTPS-ready. Another obscure feature is the preload flag, which is not officially standardized but is recognized by Chrome, Firefox, Safari, and Edge.

HSTS also has a lesser-known interaction with HTTP/2: when a server supports HTTP/2, the browser may use it only over TLS, and HSTS ensures that the connection is upgraded. Additionally, HSTS can be used for HSTS pinning, where a site pins its certificate to prevent MITM attacks, though this is less common. The HSTS preload list is a global resource that can be queried via an API, and it includes millions of domains.

SSL stripping

An attack that downgrades a secure HTTPS connection to an insecure HTTP connection.

Preload list

A list of domains hardcoded into browsers to enforce HSTS from the first connection.

max-age

The time in seconds that the browser should remember to use HTTPS.

includeSubDomains

A directive that applies HSTS to all subdomains of the domain.