What is HSTS ?
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.
The HSTS Policy is communicated by the server to the user agent via an HTTPS response header field named “Strict-Transport-Security“. HSTS Policy specifies a period of time during which the user agent should only access the server in a secure fashion. Websites using HSTS often do not accept clear text HTTP, either by rejecting connections over HTTP or systematically redirecting users to HTTPS (though this is not required by the specification). The consequence of this is that a user-agent not capable of doing TLS will not be able to connect to the site.
The protection only applies after a user has visited the site at least once, and the way this protection works is that a user entering or selecting a URL to the site that specifies HTTP, will automatically upgrade to HTTPS, without making an HTTP request, which prevents the HTTP man-in-the-middle attack from occurring.
Submission Requirements
If a site sends the preload directive in an HSTS header, it is considered to be requesting inclusion in the preload list and may be submitted via the form on this site.
In order to be accepted to the HSTS preload list through this form, your site must satisfy the following set of requirements:
- Serve a valid certificate.
- Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.
- Serve all subdomains over HTTPS.
- In particular, you must support HTTPS for the
wwwsubdomain if a DNS record for that subdomain exists.
- In particular, you must support HTTPS for the
- Serve an HSTS header on the base domain for HTTPS requests:
- The
max-agemust be at least31536000seconds (1 year). - The
includeSubDomainsdirective must be specified. - The
preloaddirective must be specified. - If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).
- The
of a valid HSTS header: (You can add this code is .htaccess)
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
You can check the status of your request by entering the domain name again in the form above, or consult the current Chrome preload list by visiting chrome://net-internals/#hsts in your browser. Note that new entries are hardcoded into the Chrome source code and can take several months before they reach the stable version.
Continued Requirements
You must make sure your site continues to satisfy the submission requirements at all times. Note that removing the preload directive from your header will make your site immediately eligible for the removal form, and that sites may be removed automatically in the future for failing to keep up the requirements.
Deployment Recommendations
If your site is committed to HTTPS and you want to preload HSTS, we suggest the following steps:
- Examine all subdomains (and nested subdomains) of your site and make sure that they work properly over HTTPS.
- Add the
Strict-Transport-Securityheader to all HTTPS responses and ramp up themax-agein stages, using the following header values:- 5 minutes:
max-age=300; includeSubDomains - 1 week:
max-age=604800; includeSubDomains - 1 month:
max-age=2592000; includeSubDomains
During each stage, check for broken pages and monitor your site’s metrics (e.g. traffic, revenue). Fix any problems that come up and then wait the full
max-ageof the stage before you move on. For example, wait a month in the last stage. - 5 minutes:
- Once you’re confident that there will be no more issues, increase the
max-ageto 2 years and submit your site to the preload list:- 2 years, requesting to be preloaded:
max-age=63072000; includeSubDomains; preload
- 2 years, requesting to be preloaded:
If you have a group of employees or users who can beta test the deployment, consider trying the first few ramp-up stages on those users. Then make sure to go through all stages for all users, starting over from the beginning.
Consult the Mozilla Web Security guidelines and the Google Web Fundamentals pages on security for more concrete advice about HTTPS deployment.
Preloading Should Be Opt-In
If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default. We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list by the time they find they need to remove HSTS to access certain subdomains. Removal tends to be slow and painful for those sites.
It’s great to support HSTS preloading as a best practice, and for projects to provide a simple option to enable it. However, site operators who enable HSTS should know about the long-term consequences of preloading before they turn it on for a given domain.
Removal
Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers. Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.