HSTS (HTTP Strict Transport Security)
About 4 min read
Last updated: 2026-09-01
What Is HSTS
HSTS (HTTP Strict Transport Security) is a security mechanism where a web server instructs the browser to "always use HTTPS for future access to this domain." It is activated by including the Strict-Transport-Security header in HTTP responses, and the specification was standardized as RFC 6797 (November 2012).
Without HSTS, when a user accesses http://example.com, communication occurs in plaintext for a brief moment until the server redirects to HTTPS. This moment creates an opportunity for a man-in-the-middle attack (SSL stripping). Once a browser has received the HSTS policy, it rewrites the URL to HTTPS before sending the request, so that plaintext round trip no longer happens.
The second pillar is how certificate errors are handled. If certificate validation fails on a domain covered by HSTS, the browser must terminate the connection, and the user cannot click through a warning screen as they normally could. Even if an attacker presents a forged certificate, no user action can push past it - that is the difference from ordinary HTTPS.
On the other hand, the browser only learns of this instruction after receiving the header. The very first visit to the domain is not covered by HSTS, and the RFC itself lists this as a weakness. The Preload list described below exists to close that gap.
HSTS Configuration and Directives
HSTS is configured with the following response header.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- max-age: Duration in seconds for the browser to remember the HSTS policy. 31536000 (1 year) is also the minimum that the Preload list requires, which is why it is commonly used. For initial deployment, start with 300 (5 minutes) or 86400 (1 day) and gradually extend once confirmed safe.
- includeSubDomains: Applies HSTS to subdomains as well. Verify that all subdomains like
api.example.comandcdn.example.comsupport HTTPS before enabling. Subdomains operating on HTTP only will become inaccessible. - preload: A flag indicating intent to register on the HSTS Preload list. RFC 6797 defines only two directives, max-age and includeSubDomains; preload was added later for the browser-side list and sits outside the specification. Since the specification requires unknown directives to be ignored, adding the flag by itself does nothing - a separate application is required.
Among security headers, HSTS has few settings to get wrong and can reliably enforce encrypted communication via TLS/SSL. Note, however, that once a browser has stored the policy, the domain cannot be served over HTTP again until max-age expires. Confirm how far your HTTPS coverage reaches, and start with a small max-age before extending it.
How the HSTS Preload List Works
Standard HSTS has a "first-visit problem." Since the browser receives the HSTS header on the first HTTPS access, HSTS does not function when a user visits the domain for the very first time.
The HSTS Preload list addresses this problem. It is a list of HSTS-enabled domains built into browsers: the list shipped in the Chrome source code is the original, and Firefox, Safari, and Edge maintain lists derived from it. Applications are submitted through hstspreload.org, and once a domain is registered, HTTPS is enforced from the very first visit, even for domains the user has never accessed.
Requirements for Preload list registration:
- Using a valid digital certificate
- Redirecting from HTTP to HTTPS on the same host name, if port 80 is served
- Serving all subdomains over HTTPS (including
wwwwhen a DNS record for it exists, and internal subdomains that are not publicly available) max-ageis 31536000 (1 year) or moreincludeSubDomainsandpreloaddirectives are included
The main caveat is how hard it is to undo. Even after a removal request, it takes several months for the change to reach users through browser updates, and the site states explicitly that propagation to browsers other than Chrome is not guaranteed. New registrations likewise take months to reach stable releases. Carefully verify that all subdomains support HTTPS before registering.
Note that as of August 2026, hstspreload.org takes the position that while HSTS itself is recommended, preloading is not. Chrome and Safari now upgrade HTTP page navigations to HTTPS regardless of whether an HSTS policy exists, so preloading only helps in the narrow case where an attacker blocks that upgrade. Treat deploying HSTS and joining the Preload list as separate decisions.
HSTS Deployment Considerations and Gradual Approach
While HSTS is powerful, misconfiguration can render a site inaccessible. The following gradual approach is recommended.
- Step 1: Set
max-age=300(5 minutes) and verify the entire site works correctly over HTTPS - Step 2: Extend to
max-age=86400(1 day) and operate for about a week to confirm no issues - Step 3: Expand to
max-age=31536000; includeSubDomains - Step 4: Only if you choose to join the Preload list, review the caveats above, then add
preloadand submit the application
The case that needs the most attention is anywhere your own domain or its subdomains are referenced over HTTP. With includeSubDomains enabled, the browser rewrites those references to HTTPS, so a subdomain that does not support HTTPS will simply fail to load. Before enabling it, confirm that every subdomain, including staging and internal ones, responds over HTTPS. Resources delivered over HTTP from a third-party domain fall outside the scope of HSTS; those are blocked by the browser as Mixed Content whether or not HSTS is in place.
Combining with CSP's upgrade-insecure-requests directive automatically rewrites HTTP resource references within the page to HTTPS, mitigating Mixed Content issues during the transition period.
To learn more about this topic, see How HTTPS and TLS Work: The Encryption Behind Secure Communication.
Common Misconceptions
- HSTS is unnecessary if you redirect to HTTPS
- During the HTTP to HTTPS redirect, the initial request is sent in plaintext. A man-in-the-middle attack (SSL stripping) can succeed during this moment. HSTS rewrites HTTP requests to HTTPS on the browser side, defending against attacks that redirects cannot prevent.
- Setting HSTS immediately applies to all users
- Standard HSTS only becomes effective after the browser receives the header, so users are not protected on their first visit. The HSTS Preload list is the way to enforce HTTPS from the first visit, but undoing a registration takes several months, so decide only after confirming that the domain and all of its subdomains can stay on HTTPS for the long term.