Balancing frontend security and performance with HTTP Strict Transport Security

As an industry, we’re seeing a trend towards more secure end user experiences. Service workers and HTTP/2 working strictly over HTTPS demonstrates this movement. Additionally, Google announced in late 2015 that their indexing system would now prefer indexing HTTPS URLs over HTTP URLs to motivate developers to move to HTTPS. Generally, the quick fix solution here is to enforce an HTTP to HTTPS redirect for the end user, but this still leaves the end user open to man-in-the-middle (MITM) attacks in which a malicious end user can manipulate the incoming response or outgoing request over a non-secure HTTP connection. Furthermore, the redirect method adds an additional request that further delays subsequent resources from loading in the browser. Let’s explore how HTTP Strict Transport Security (HSTS), a frontend security technique, can address these issues.

What is HSTS?

The HTTP Strict Transport Security (HSTS) header is a security technique that enforces the browser to rewrite HTTP requests into HTTPS requests, for a secure connection to the origin servers during site navigation. From HTTP Archive, 56% of base pages are using the HTTP Strict Transport Security technique and this number will continue to grow as HTTPS adoption continues to grow. Not only does this header provide browser-level security, but it also proves to be a frontend optimization technique to improve the end user experience. By utilizing this header and the associated parameters, we can avoid the initial HTTP to HTTPS redirects so that pages load faster for the end user. As mentioned in High Performance Websites by Steve Souders, one of the top 14 rules in making websites faster is to reduce the number of HTTP requests. By eliminating HTTP to HTTPS redirects, we are essentially removing a browser request and loading the remaining resources sooner rather than later.

The example in Figure 1-1 demonstrates how the browser performs a redirect from HTTP to HTTPS, either using a redirect at a proxy level or at the origin infrastructure. The initial request results in a 302 Temporary Redirect and returns location information in the headers, which directs the browser to request the same page over HTTPS. In doing so, the resulting page is delayed for the end user due to time spent and additional bytes downloaded.

When using the Strict Transport Security technique in Figure 1-2, we immediately see an improvement in delivery due to the elimination of the HTTP to HTTPS redirect for subsequent non-secure requests. Instead, the browser performs a 307 Internal Redirect for subsequent requests and a secure connection is initialized with the origin infrastructure. From a frontend performance standpoint, initial header bytes are eliminated due to the removal of 302 Temporary Redirect and the page is delivered sooner to the end user over HTTPS.

Note

Keep in mind that an initial 302 Temporary Redirect or 301 Permanent Redirect is still needed to ensure the resulting HTTPS request returns the Strict Transport Security header; however, any subsequent requests will result in a 307 Internal Redirect at the browser and will continue to do so until the time to live (TTL) expires, which is described in the next section.

The parameters

In order to take advantage of the Strict Transport Security header from both a performance and security point of view at the browser, the associated parameters must be utilized. These parameters include the max-age, includeSubDomains, and preload directives:

Strict-Transport-Security:
      _max-age_=_expireTime_
      [; _includeSubDomains_]
      [; _preload_]

The max-age directive allows developers to set a time to live (TTL) on the browser’s enforcement of a secure connection to a website through the security header. The optional includeSubDomains directive allows developers to specify additional pages on the same website domain to enforce a secure connection. Lastly, the optional preload directive allows developers to submit sites to a Strict Transport Security list maintained on a per-browser basis to ensure that secure connections are always enforced. Preload lists have various requirements including a valid browser certificate and a full HTTPS site including subdomains.

Last thoughts

With a simple security technique, we eliminate MITM attacks over a non-secure connection. While this method proves successful, the security protocol should be investigated to ensure MITM attacks can be avoided over a secure connection as well. Several SSL and TLS versions have exploitable vulnerabilities that should be considered while moving to a secure experience and deploying this security enhancement.

As a basic frontend technique, reducing the number of redirects, by default, reduces the number of browser requests, which can help to improve page load times. We are essentially moving the redirect from a proxy or origin infrastructure level to the browser for the “next” HTTP request. As with any additional headers, developers are often worried about the size of requests being downloaded in browser. The latest HTTP/2 provides header compression, which reduces the size of requests. Additionally, for non-changing header values, HTTP/2 now maintains header state without having to re-send duplicate headers during a session. Given these new benefits, we can safely utilize additional security techniques such as Strict Transport Security, without affecting overall page delivery performance. While a single HTTP header serves as a great example of bridging the gap, we will cover other techniques such as Content Security Policy to address both performance and security concerns in a similar manner.