HSTS Cheat Sheet

This page is a concise overview of all supported features and directives in HTTP Strict Transport Security. It can be used as a quick reference guide to identify valid and invalid directives and values, contains example policies and guidance on how to use HSTS effectively.


Directives - a list of all HSTS directives.

max-age | includeSubDomains | preload


Directives

 

max-age=[seconds];

This is the time, in seconds, that the browser should cache and apply the given HSTS policy for.

 

includeSubDomains;

This flag indicates that the browser should also apply this policy to all subdomains below the current domain.

 

preload;

This flag indicates that the site wishes to be included in the HSTS Preload list.


Example policies

Here are a few example policies ranging in purpose and strength:

To start out, sites should issue a very relaxed HSTS policy for testing purposes. It is also possible to issue a policy on certain endpoints only advertised to staff or beta testers for example. That way only they will pick up the policy.

Strict-Transport-Security: max-age=600

This policy will only apply for 10 minutes so if it does have undesired side effects they will not last long until the policy expires.



Once you are sure that you can meet the requirements of HSTS you can introduce the includeSubDomains directive should you wish.

Strict-Transport-Security: max-age=600; includeSubDomains

Again, the low max-age means you can stop issuing the policy and it will expire quickly for those that have received it. After this the next step is to start increasing the max-age value.



You should aim for a max-age value of 1 year after making many, small incremental increases to test your ability to support HSTS.

Strict-Transport-Security: max-age=31536000; includeSubDomains



The final step for a HSTS policy is to include the preload directive for inclusion in the HSTS Preload list.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Warning: You should ensure that you fully understand the implications of HSTS preloading before you include the directive in your policy and before you submit. It means that your entire domain and all subdomains, including those managed or maintained by third parties, will only work with HTTPS. Preloading should be viewed as a one way ticket. Whilst it is possible to be removed, it can take a long time and you may not be removed from all browsers.


Chromium HSTS Preload List:
https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json

Chromium HSTS removal list:
https://bugs.chromium.org/p/chromium/issues/detail?id=527947

Firefox HSTS Preload List:
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc

Tor HSTS Preload List:
https://gitweb.torproject.org/tor-browser.git/plain/security/manager/boot/src/nsSTSPreloadList.inc

Chromium HSTS Submission site:
https://hstspreload.appspot.com/
API Endpoints:
https://hstspreload.appspot.com/api/v2/status?domain=scotthelme.co.uk
https://hstspreload.appspot.com/api/v2/preloadable?domain=scotthelme.co.uk
https://hstspreload.appspot.com/api/v2/pending

Check HSTS header on Security Headers:
https://securityheaders.io

Testing the HSTS Preload Process:
https://scotthelme.co.uk/hsts-preload-test/

HSTS Preloading:
https://scotthelme.co.uk/hsts-preloading/

Introduction to HSTS:
https://scotthelme.co.uk/hsts-the-missing-link-in-tls/



sources

HSTS RFC:
https://tools.ietf.org/html/rfc6797