As we all know by now, having a site that is SSL encrypted (https) is critical for ensuring the security of your site’s visitors, and for SEO – Google has made it clear that SSL encrypted sites will get some extra brownie points, including the satisfying green lock in the browser address bar:
In order to make sure that all visitors are reaching the https version of the site, web developers will generally set up 301 redirects from the http version to the https version for those users who type in the http link, or are following links from other sources that still point to the http version of the URL.
However, what many people don’t realize is that the redirect does not fully protect the site visitor, since there is a window of opportunity (however small) between when the visitor requests the http version of the site, and when it reaches the https destination, for a type of attack called a “man in the middle” attack. Some examples of these types of attacks are protocol downgrade attacks and cookie hijacking.
HSTS security header to the rescue
Security headers offer ways to tell browsers how to treat content on a web page. For example, Content Security Policies (CSP) allow site owners to whitelist certain types of content that they know to be safe for loading on a web page.
Another type of security header, and the one that’s relevant to the issue described here, is the HTTP Strict Transport Security (HSTS) header. HSTS was set up by web giants including Google and PayPal to allow site owners to instruct browsers to always go straight to the https version: don’t pass go, don’t redirect on the server, don’t collect 200 bitcoin. This removes the window for the man-in-the-middle attacker since the http version of the site is never accessed, not even for a second.
In order for sites to be HSTS-enabled, the HSTS header “Strict-Transport-Security” must be in place, the site must meet a number of criteria outlined here, and then be submitted to the HSTS Preload list.
Because security is extremely important to us, we have implemented HSTS for all our client’s websites. In order to complete the process, all our clients have to do is fill out the HSTS Preload form to get added to it.
The drawbacks of implementing HSTS
While the benefits of implementing HSTS are clear, it’s important to understand what it entails, since it could prove challenging:
- All subdomains must also be HSTS and this doesn’t necessarily work for everyone.
- If for some reason you would like to remove your site from the HSTS Preload list, you can do so with this HSTS removal form, but it can take months for your site to be removed.
What do Strattic customers have to do in order to get HSTS working?
Strattic has HSTS preload eligibility support set up automatically for all sites. If your site is on Strattic, the only thing you need to do is enter your domain and then submit the form on hstspreload.org to add your site to the HSTS preload list. And then wait to be accepted which could take several weeks.