HSTS Implementation

What is HSTS

HSTS is the great little response header that tells a browser to always use SSL/TLS to communicate with your site. It doesn’t matter if the user, or a link they are clicking, specifies HTTP, HSTS will remove the ability for a compatible browser to use HTTP and will enforce the use of HTTPS. This still leaves a user vulnerable on their very first connection to a site though. HSTS preloading fixes that.

If a site uses SSL/TLS, and redirects traffic from HTTP to HTTPS using a 301/302, then their implementation can’t be complete without issuing the HSTS response header. This protects the user in every circumstance apart from their very first visit to the site.

In this post, we will overview of all supported features and directives in HTTP Strict Transport Security. This post can be used as a quick reference guide to identify valid and invalid directives and values. I also provide a working example of policies and guidance on how to use HSTS effectively.

Directives – a list of all HSTS directives.

• max-age
• includeSubDomains
• preload

HSTS Directives
This is the time, in seconds, that the browser should cache and apply the given HSTS policy for.
This flag indicates that the browser should also apply this policy to all subdomains below the current domain.
This flag indicates that the site wishes to be included in the HSTS Preload list.

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.
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.
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.
The final step for an 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.

What is HSTS preloading

HSTS Preloading is a mechanism whereby a list of hosts that wish to enforce the use of SSL/TLS on their site is built into a browser. This list is compiled by Google and is utilised by Chrome, Firefox and Safari. These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is already aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP.
This isn’t to say that the host needs to stop issuing the HSTS response header, this must be left in place for those browsers that don’t use
preloaded HSTS lists.

To implement HSTS using .htaccess
The env=HTTPS is used to make the rule only activates when it’s https.

Useful Links

• Check HSTS preload status, eligibility & submission
• Check HSTS header on Security Headers