If you are concerned about the security of your website, you would want your visitors to always visit it via HTTPS. Although simple HTTP to HTTPS redirects do work most of the time, there are certain type of cyberattacks which may be able to bypass such redirects and trick your visitors into willingly giving away sensitive information, like credit card numbers, personal names and addresses, etc.

Against what types of attacks does HSTS protect my website?

HTTP Strict Transport Security (HSTS) mainly protects your website against man-in-the-middle (MiTM) attacks, cookie hijacking (also called session hijacking), and protocol downgrade attacks.

Man-in-the-middle attacks, or MiTM attacks for short, is a general term for when an unauthorized actor positions himself/herself in a conversation between a user and an application. These attacks allow perpetrators to intercept confidential data and insert malicious data and links in a way indistinguishable from legitimate data.

Let's imagine you are in a restaurant, and you connect to one of the available Wi-Fi hotspots listed on your laptop or smartphone. You decide to check a bank statement, so you visit your online banking page. Little do you know that the access point to which you are connected is a hacker’s device. They are intercepting your initial HTTP request and then redirecting you to a clone login page which looks exactly like the real login page of your bank. This is known as an SSL stripping attack. The hacker establishes their own HTTPS connection to the bank's website (posing as the user) and maintains the HTTP connection with the user (posing as the bank's website). When you attempt to log in with your real username and password, your private data is exposed to the hacker and captured. Before entering any sensitive data on a website, we would highly recommend that you make sure that there's a padlock in the URL bar, showing that the connection is indeed secure. At this point, using Two-Factor Authentication (2FA) for your Internet banking may seem like a very important thing.


There are different types of session hijacking,  but they all generally involve guessing or intercepting an existing session cookie, or tricking the user into signing in with a session ID created by the attacker. If you are connected to an unsecured Wi-Fi, a criminal could utilize a "packet sniffing" tool to monitor your network traffic and steal your session.

Another example would be for you to receive an email with a link to a login form for the website the attacker wants to access. The email looks similar to legitimate ones you have received in the past, so you log in with the phony session ID, giving the attacker a way in the door. Usually, such scam emails have a tell - the layout of the message could be a bit disrupted and there could be serious spelling or grammar errors. Also, the headers of the email can usually reveal whether the message was sent from an unauthorized outgoing mail server.

There are many other similar examples, so you should definitely be vigilant when entering any sensitive data on websites, even trusted ones.

The HTTP Strict-Transport-Security (HSTS)

How can I protect my website visitors?

Enabling HTTP Strict Transport Security (HSTS) is a simple way to add another security layer to your website, especially if it is one which somehow collects sensitive information. Of course, you need to issue and install an SSL certificate for your domain name first. Then you just need to add a few lines to the .htaccess file located in your website's document root.

To summarize, the main requirements of HSTS are:

  • Redirect from HTTP to HTTPS on the same host. i.e. http://example.com to https://example.com and http://www.example.com to https://www.example.com;
  • Redirect to the canonical hostname (www or non-www) on HTTPS only. (i.e. after #1 above);
  • Send the Strict-Transport-Security (STS) HTTP response header when on HTTPS only, including on the canonical redirect (#2 above).

To enable HSTS for your website and set up a redirect from non-www to www at the same time, add the following lines to your .htaccess file (the order of the lines is important):

RewriteEngine On

# Set HSTS env var only if HTTPS
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=HSTS:1]

# Redirect HTTP to HTTPS on the same host
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# Redirect non-www to www (HTTPS only)
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# Set HSTS header for 365 days including subdomains conditionally if request is over HTTPS only (based on HSTS env var)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HSTS

If you prefer using non-www URLs instead of www, you can add the following lines instead:

RewriteEngine On

# Set HSTS env var only if HTTPS
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=HSTS:1]

# Redirect HTTP to HTTPS on the same host
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# Redirect www to non-www (HTTPS only)
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^ https://your-domain-name.com%{REQUEST_URI} [R=301,L]

# Set HSTS header for 365 days including subdomains conditionally if request is over HTTPS only (based on HSTS env var)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HSTS

When redirecting from www to non-www URLs, make sure to replace your-domain-name.com with your actual domain name.

Detailed instructions for setting this up on the ICDSoft servers can be found in the "How to enable HSTS?" knowledge base article, where additional information about avoiding certain configuration conflicts is also available.

Limitations of HSTS

A key downside of using HSTS is that a visitor who cannot connect through HTTPS will be unable to view and use the website. Additionally, as "HTTP Strict-Transport-Security" is a response header, it requires the user agent to first visit the website to learn that it uses HSTS. This means that the initial request remains unprotected from attacks if it uses an unsecure protocol such as plain HTTP, or if the URI for the initial request is obtained over an unencrypted channel.  Also, the HSTS header is ignored by the browser if the page is served over HTTP, which is why it is important to automatically redirect every HTTP request to HTTPS.

A way around the limitations (the HSTS Preload list)

The solution to the unprotected initial request is Chrome's HTTP Strict Transport Security (HSTS) Preload list. All major browsers enforce secure connections to domains included in the preload list, leaving HTTP requests a relic of the past. This list is managed by Google. If you want to add your website to the HSTS preload list, you can do so via the hstspreload.org website. As described there, you should keep in mind that there are certain submission requirements, and your website should continue to satisfy them at all times. Otherwise, your website may be removed automatically from the list for failing to meet the requirements.

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. If you cannot have all applications on your primary domain and its subdomains working fully over HTTPS, then you should not submit your domain name to the HSTS Preload list, and you should not include the preload directive by default in your .htaccess file, as this could in time automatically add your website to the HSTS Preload list.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HSTS

In conclusion

The security of your website should be of utmost importance to you, because you must protect your visitors and users and not put their data at risk. In addition to HTTPS and HSTS, there are additional headers you could add to your setup, and certain methods you could remove from the configuration of the web server, so a higher level of security is in place. We will write about this in one of our next posts.

Author

A web hosting provider since 2001. We host over 58,000 websites for customers in over 140 countries around the globe.