HTTP Strict Transport Security

HSTS (HTTP Strict Transport Security) header to ensure all communication from a browser is sent over HTTPS (HTTP Secure). This prevents HTTPS click-through prompts and redirects HTTP requests to HTTPS.

Before implementing this header, you must ensure all your website page is accessible over HTTPS else they will be blocked.

HSTS header is supported on all the major latest version of a browser like IE, Firefox, Opera, Safari, and Chrome. There are three parameters configuration.

Parameter ValueMeaning
max-ageDuration (in seconds) to tell a browser that requests are available only over HTTPS.
includeSubDomainsThe configuration is valid for the subdomain as well.
preloadUse if you would like your domain to be included in the HSTS preload list

So let’s take an example of having HSTS configured for one year, including preload for domain and sub-domain.

Apache HTTP Server

You can implement HSTS in Apache by adding the following entry in httpd.conf file

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

Restart apache to see the results

Nginx

To configure HSTS in Nginx, add the next entry in nginx.conf under server (SSL) directive

add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

As usual, you will need to restart Nginx to verify

Cloudflare

If you are using Cloudflare, then you can enable HSTS in just a few clicks.

  • Log in to Cloudflare and select the site
  • Go to the “Crypto” tab and click “Enable HSTS.”

Select the settings the one you need, and changes will be applied on the fly.

Microsoft IIS

Launch the IIS Manager and add the header by going to “HTTP Response Headers” for the respective site.

Restart the site

HTTP Strict Transport Security

As the name suggests, HSTS is a mechanism that forces browsers to use a secure web connection.

In fact, we can call HSTS the ‘missing link’ in the secure web connection chain. Why?

With end-to-end encryption, SSL lays the foundation for a secure and authorized connection. In an ideal SSL implementation, we can ensure that the data is not altered or monitored by a third party during transmission, or verify that the person we’re communicating with is the intended recipient of the traffic.

I say ‘ideal’ because the partial implementations that some web applications use, such as secure connections only in login and checkout pages, pose a huge threat. The risks that arise with partial implementations are covered in detail in HTTP Cookie Hijacking in the Wild (DEF CON 24 conference).

If we do not force all our pages to be transmitted over a secure connection, attackers can easily forward their targets to surf the web on the unsafe connection or convert the HTTPS traffic to HTTP by launching MITM attacks (such as SSL Strip).

That’s not all. Expired or invalid certificates are highly threatening to your secure connections. Your website’s reputation will also be damaged if your users are confronted with such easily preventable problems.

Is There Any Way to Further Improve HTTPS Protection on Your Website?

If you want to take full advantage of SSL, you have to convert all HTTP requests to HTTPS, and load all images, scripts, style files and other files over a secure connection. You also have to go as far as preventing the user from dismissing certificate errors.

Doing all this manually is rather difficult, especially in case of a certificate error when you have to prevent the user from accessing your website.

Thankfully, the HSTS specification published in November 2012 is the solution to this problem. All we have to do is to set a security header (Strict-Transport-Security) on our web page response. With this security header we can direct our browser to:

  • Convert all requests to an HTTPS connection
  • In case of a certificate related error such as an expired certificate, prevent the user from browsing the website anyway
  • Cache this setting for a specified amount of time

Strict Transport Security Header Example

Here is an example of how to use this header:

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

max-age:  This directive allows us to specify the amount of time (in seconds) that the content of the header will be stored in the browser cache.

There are two more significant specifications in the HSTS implementation: the includeSubdomains parameter and the preload parameter. We can enforce the same strict, secure connection on all the subdomains of the website using the includeSubdomains parameter.

First Request and Preload

We can only set the HSTS header over a secure connection. Just like Public Key Pinning (which is another HTTPS security header), HSTS is based on Trust on First Use (TOFU). This means that we have to manually redirect the users, on their first HTTP request, to the HTTPS version of our website. In its response, there will be an HSTS header, meaning that the browsers will store it in their cache. The next time an unsafe (HTTP) connection arises, it will automatically be redirected to a secure connection.

The obvious question is: could a hacker override this first HTTP request with a MiTM attack?

Unfortunately, the answer is yes. However, this time, the HSTS preload list comes to the rescue.

We need to add the preload directive to our HSTS header for the website to be eligible for inclusion in the HSTS preload list. The browser will check whether or not a site is included in the list and will simply refuse to load it over an insecure connection.

Additional Requirements for the HSTS Preload List

Adding our website to the HSTS Preload List has some further requirements:

  1. You need to serve a valid certificate.
  2. You must redirect from HTTP to HTTPS on the same host, meaning that the HTTPS traffic for example.com should go through example.com (not through any other domain such as secure.example.com).
  3. You must support HTTPS for all subdomains, particularly the www subdomain.
  4. You have to set the following values for the HSTS header:
  • The max-age must be at least 31536000 seconds (1 year)
  • The includeSubDomains and preload directives must be specified
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Check Your Security Headers

HTTP security headers are a fundamental part of website security

‘HTTP Security Response Headers’ allow a server to push additional security information to web browsers and govern how the web browsers and visitors are able to interact with your web application.

Scroll to Top