HTTP Strict Transport Security Cheat Sheet
Last revision (mm/dd/yy): 08/10/2016
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
The specification has been released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF. (Reference see in the links at the bottom.)
HSTS addresses the following threats:
Simple example, using a long (1 year) max-age:
If all present and future subdomains will be HTTPS:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Recommended: If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari), then use the header below. Sending the preload directive from your site can have PERMANENT CONSEQUENCES and prevent users from accessing your site and any of its subdomains if you find you need to switch back to HTTP. Please read the details at hstspreload.appspot.com/#removal before sending the header with "preload".
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.
Site owners can use HSTS to identify users without cookies. This can lead to a significant privacy leak.
Cookies can be manipulated from sub-domains, so omitting the include "includeSubDomains" option permits a broad range of cookie-related attacks that HSTS would otherwise prevent by requiring a valid certificate for a subdomain. Ensuring the "Secure Flag" is set on all cookies will also prevent, some, but not all, of the same attacks.
Authors and Primary Editors