HTTP Strict Transport Security (HSTS)

What is HSTS?

HSTS stands for HTTP Strict Transport Security. It is a mechanism that lets you make sure your website or web application is only accessed using secure HTTPS (SSL/TLS) connections. If you enable HSTS for your domain name, all web browsers will make encrypted connections to web pages hosted on this domain, even if the user tries to force unencrypted connections.

HSTS is supported by all current versions of major browsers and user agents, such as Google Chrome, Mozilla Firefox, the Chromium project, Microsoft Edge and Internet Explorer, Apple Safari, Opera, and more. However, there are still a few mobile browsers that do not support HSTS. If a user navigates to the unencrypted version of an HTTPS site using such a browser, the browser will allow the unsafe connection.

HTTP Strict Transport Security is formally defined in the IETF RFC-6797 specification.

What does HSTS protect against?

Secure connections between browsers and web servers are a necessity to avoid various attacks such as cookie hijacking. HSTS is an additional layer of protection against downgrade attacks like SSLStrip that force the browser to drop an existing HTTPS connection and go back to insecure HTTP. HSTS is considered a vital component of web security, and you should consider implementing it in your security policy.

How does HSTS work?

HTTP Strict Transport Security is enforced by the browser, not the web server. All the web server does is use a special HTTP header to inform browsers that they should always use secure connections. Here is a simplified process for an example domain and website:

1. The user’s browser makes an insecure connection to your website at example.com using HTTP. It is a first-time connection from this browser and can be initiated if the user simply types example.com in the address bar, enters the full URL http://example.com/ into the browser, or clicks a link from another site that directs them to http://example.com/.
2. Your web server responds by sending the browser a redirect HTTP response header that tells it to use an encrypted connection (HTTPS). This causes the browser to force HTTPS communication.
3. The user’s browser tries to access the same website again but using https://example.com/ for a secure connection.
4. The web server responds by sending an HSTS header to the web browser. This informs the browser that from now on, it should always access this domain using HTTPS and never using HTTP. The browser stores that information locally and remembers it for up to 2 years.

What does the HSTS header look like?

An HSTS header is constructed like any standard HTTP header. Here’s a typical example:

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

This header is composed of three parts:

• The Strict-Transport-Security header keyword, followed by a colon.
• The mandatory max-age directive that says how long the browser should store HSTS information for the current domain. This is specified in seconds, and the recommended value is 63072000 (2 years).
• The optional includeSubDomains directive that instructs the browser to also apply the HSTS policy to all subdomains. If this is not specified and you only send an HSTS header for your primary domain such as example.com, HSTS won’t apply to www.example.com or any other subdomains.
• The optional preload directive to request either HSTS preloading or removal from the HSTS preload list (see below for an explanation of preloading). Note that this parameter is not part of the official specification.

How to protect yourself using HSTS?

To enable HSTS, you need to be a web server administrator. Configure your web server to send HSTS response headers with all HTTPS responses automatically. You can configure HSTS headers for any web server, including Apache, nginx, Microsoft IIS, and more.

In addition, you also need to configure the server to redirect all HTTP requests to HTTPS. This is because browsers will ignore any HSTS headers sent without encryption (over plain HTTP), as these could easily be forged in a man-in-the-middle attack (MITM). For the same reason, HSTS also won’t work if you are using self-signed public-key certificates.

Important: Before you turn on HSTS, make sure your pages are accessible via HTTPS. Otherwise, HSTS will make your domain inaccessible to browsers.

How to turn off HSTS?

To turn off HSTS, modify an existing HSTS header and downgrade max-age to 0. Next time a browser sends an HTTPS request to your server, it will be informed that HSTS for the current domain has expired and will no longer enforce it.

Note that you can also set max-age to a very short time for testing purposes and then set it to its final large value once testing is completed. This is far easier and safer than trying to manually remove HSTS information from browser caches (which might not be possible if you’re dealing with a public server).

What is the HSTS preload list?

The HSTS preload list is an unofficial initiative by the makers of two major browsers, Google Chrome and Mozilla Firefox, intended to solve the problem of untrusted first visits. The idea is that your browser comes with a built-in (preloaded) HSTS list of domains that are ready for HTTPS-only communication from the first visit. This means that for Chrome/Firefox users, such domains are accessed securely from the very first request.

How to put your domain on the HSTS preload list

If you want your domain to be on the HSTS preload list, you need to meet a few requirements:

1. All your websites across all your domains and subdomains (as specified in your DNS records) must have valid SSL/TLS certificates and use up-to-date SSL/TLS ciphers.
2. If any of your web pages can be accessed using HTTP, you must redirect all such requests to HTTPS.
3. Configure the HSTS header for the base domain with a max-age of at least 1 year (31536000), the includeSubDomains directive, and the preload directive. For example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4. Go to the hstspreload.org website and fill in the form to submit your domain for inclusion on the preload list. If you meet the conditions, Chrome and Mozilla will add your domain to their preload lists with a future release (it may take a few months, however).

How to remove your domain from the HSTS preload list

If you decide that you no longer want your domain on the HSTS preload list, you must remove the preload directive from your domain. Note that your domain doesn’t have to be on the preload list already but must at least be queued for inclusion. You cannot remove a domain if you don’t serve an HSTS header or don’t have a valid TLS/SSL certificate. As soon as browsers notice that your domain no longer has the preload directive, it will be queued for removal.

Note that the removal process may also take a few months, just like adding to the preload list.

Frequently asked questions

Related blog posts

• Why websites need HTTP Strict Transport Security

Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler