HTTP Strict Transport Security (HSTS) is a directive expressed within an HTTP response header that forces any browsers to strictly serve a website over HTTPS. Clients will remember that they have seen an HSTS header (for the duration of the max-age setting) from a site and make requests over HTTPS even if the client (or a link) tells them to contact the site via HTTP, and will no longer allow users to bypass security warnings from invalid/expired certificates.
HSTS is universally supported and respected by compliant web browsers. It's an IETF standardized directive specified in RFC 6797, and has become a de facto requirement for security-focused organizations. And although HTTP first launched in approximately 1991, HSTS came into existence over 20 years later in 2012.
Administrators considering adding this header should be aware that there is no method to take back an HSTS header once a browser has seen it; any self-signed, expired, or improperly scoped certificates (anywhere under the domain if the includeSubdomains flag is used) will become unusable.
What makes HSTS useful?
While HSTS isn't a requirement, it's a simple measure that can automatically boost security for clients and applications. HSTS was invented to tackle some common cybersecurity threats:
Protocol downgrades – An HTTPS connection is transformed into an HTTP connection, either accidentally or via bad actors. This leaves data more vulnerable in transit.
Man-in-the-middle (MITM) attacks – A hacker can intercept data flowing between client and web server, or gain access to sensitive information by diverting clients to a fake website served over HTTP. Attackers can also serve unauthorized, untrusted certificates to users to compromise their security upon acceptance.
Cookie hijacking – An attacker gains access to a user's session cookies in transit and attempts to impersonate them.
In the first scenario, the HSTS header will prevent HTTPS connections from becoming HTTP connections. The browser remembers a given website's HSTS status, which the web server passes back to the client using the Strict-Transport-Security directive.
In the second, websites that clients have previously accessed will retain this same HSTS instruction and refuse to serve counterfeit sites. In the case of certificate-based MITM attacks, HSTS will stop users from bypassing warning messages alerting them to such invalid certificates. Normally, browsers would present an "I understand the risks" button on the warning page that'll be removed if an unexpired HSTS header has been cached from previous visits (or a pre-load list).
In the third, HSTS enforcement prevents cookie theft by ensuring all cookies are transmitted via HTTPS. Encryption prevents these cookies from being human-readable.
HSTS redirects are also incredibly fast—adding little measurable latency to each HTTP request. This makes it a viable option for boosting security at scale without performance penalties.
How does HSTS work?
When HSTS is enabled, the following happens from request to response:
A user visits a website, either for the first time or as a repeat visitor.
The client requests the website, and the web server responds with a
Strict-Transport-Securityresponse header. This tells the web browser that the site is strictly accessible via HTTPS for an expressed period of time—much like a cache temporarily retains website data.An HTTPS connection is maintained for the duration of the session, and this becomes the standard behavior for all subsequent sessions unless otherwise changed.
HTTP Strict Transport Security is a lasting measure, but it doesn't remain active indefinitely. Establishing HSTS introduces an expiry date, after which the directive will no longer take effect. However, the HSTS directive is reset each time a client accesses the website in question, as long as the visit occurs within that window. Most authorities recommend setting HSTS expiration dates one to two years in the future.
This is true for all subdomains of that website as well—while offering protections in case a user clicks a URL served via HTTP. An additional HSTS preloading option exists within major browsers—resembling an allowlist—that activates immediately upon browser startup. This helps sidestep the initial insecure HTTP request needed to serve the website for the first time and enforces HTTPS.
The browser continually updates these preload lists. Specifically, Google Chrome lets users include HSTS-only domains via form submission and hard codes them accordingly to further strengthen these protections.
Does HAProxy support HSTS?
Yes! HAProxy products offer streamlined support for SSL termination and HSTS, preventing man-in-the-middle attacks and protocol downgrades. This is possible by adding a single line to your HAProxy configuration—in your backend, frontend, or named defaults section—and therefore enabling the Strict-Transport-Security response header. You can apply these settings across all domains and subdomains and easily manage SSL/TLS certificate expiry.
To learn more about HSTS in HAProxy, check out our HAProxy SSL Termination (Offloading) Everything You Need to Know or HAProxy & HTTP Strict Transport Security (HSTS) blog posts.
