HSTS - HTTP Strict Transport Security
About 2 min read
HSTS (HTTP Strict Transport Security) is a security mechanism by which a web server instructs the browser to "only connect to this domain over HTTPS from now on." It was standardized as RFC 6797 in 2012. By enforcing encrypted communication via SSL/TLS, it prevents SSL stripping attacks, a type of man-in-the-middle attack. It can be deployed simply by adding a single line to the HTTP response header, making it an extremely cost-effective security measure.
What Is an SSL Stripping Attack
SSL stripping is an attack technique that Moxie Marlinspike presented at Black Hat DC in 2009. When a user accesses http://example.com, the server normally redirects them to https://example.com. The attacker intercepts this initial HTTP communication, keeping the connection with the user over plain HTTP while communicating with the server over HTTPS. From the user's perspective, the site appears as usual, but the contents of the communication are fully exposed to the attacker.
HSTS Header Directives
| Directive | Description | Recommended value |
|---|---|---|
| max-age | The number of seconds the browser remembers the HSTS policy. During this period, the browser automatically converts HTTP access to HTTPS | 31536000 (1 year) |
| includeSubDomains | Applies HSTS to subdomains as well. HTTPS is enforced for api.example.com, cdn.example.com, and so on | Recommended to set |
| preload | Indicates the intent to register on the HSTS Preload List. It is built into the browser in advance, providing protection from the very first access | Required when registering on the Preload List |
Example of a complete HSTS header:
HSTS Preload List
Ordinary HSTS has a "first-access problem." The browser receives the HSTS header only at the first HTTPS connection, and any HTTP access before that is not protected. The HSTS Preload List is a mechanism that solves this problem.
Once registered on the Preload List, major browsers such as Chrome, Firefox, Safari, and Edge enforce HTTPS from the first access. However, because removal from the list takes several months, registering while HTTPS support is still incomplete carries the risk of making the site inaccessible.
A Phased Deployment Procedure
It is safer to deploy HSTS in stages. If you set max-age=31536000 right away, any HTTPS misconfiguration could make the site inaccessible for a long period.
First verify operation for 5 minutes. Even if there is a problem, waiting 5 minutes resolves it.
Extend to 1 week. Confirm that all pages, including subdomains, work correctly over HTTPS.
One month including subdomains. Confirm that automatic certificate renewal works correctly.
The final form. The stage at which registration on the Preload List can be considered.
Using It Together with CSP
HSTS is a mechanism that enforces encryption of the communication path; it does not control the content within a page. By using it together with CSP (Content Security Policy), you can strengthen security from both the communication-path and content perspectives. The upgrade-insecure-requests directive of CSP automatically converts HTTP resource references within a page to HTTPS, and it complements HSTS. To thoroughly enforce encryption in transit, configuring both HSTS and CSP is recommended.
Also see Browser Password Safety, The Startup Security Checklist, and Public Wi-Fi Security.web security books on Amazon are recommended for learning best practices for operating HTTPS.
Was this article helpful?