Introduction
The specification has been released and published end of 2012 as (HTTP Strict Transport Security (HSTS)) by the IETF.
Threats
HSTS addresses the following threats:
- Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP
- HSTS automatically redirects HTTP requests to HTTPS for the target domain
- A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate
- HSTS does not allow a user to override the invalid certificate message
Examples
Simple example, using a long (1 year = 31536000 seconds) max-age. This example is dangerous since it lacks includeSubDomains
:
Strict-Transport-Security: max-age=31536000
This example is useful if all present and future subdomains will be HTTPS. In this example we set a very short max-age in case of mistakes during initial rollout:
Strict-Transport-Security: max-age=86400; includeSubDomains
Recommended:
- 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 preload removal before sending the header with .
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.
Problems
Site owners can use HSTS to identify users without cookies. This can lead to a significant privacy leak. Take a look here for more details.
Cookies can be manipulated from sub-domains, so omitting the 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.
Browser Support
As of September 2019 HSTS is supported by all modern browsers, with the only notable exception being Opera Mini.