HTTP Strict Transport Security for

Our road to enabling HSTS, inspired by the Yelp story.

FT Product & Technology


“A turquoise chainlink fence with a padlock in Greece” by Jason Blackeye on Unsplash

Since October 2016, when we launched the new site, has only been available over https://.

However, we still have many insecure links pointing to our site, leaving users at risk from session hijacking and protocol downgrade attacks.

Over the past few months we’ve implemented the HTTP Strict Transport Security (HSTS) specification on, to ensure that our users will only ever talk to us over a secure connection.

This is the story of how we got there, and the hurdles we hit.

What is HSTS?

HSTS is a declaration websites can make using HTTP response headers, that tells browsers to only use secure connections when talking to the site.

This is mostly defined in the IETF RFC 6797, but there is one additional directive we use that’s not included, preload.

What is preloading?

We include the preload directive to protect users that make an initial insecure request to

It states that we are happy for to be included in a list of secure sites distributed in all major browsers.

This means that even an initial insecure request will be upgraded to a secure connection automatically by the browser.

For more information on preloading, check out the HSTS Preload List Submission site maintained by the Chromium project.

Our setup

For insecure requests to, there is only ever a redirect response.

$ curl -I -X GET http://ft.comHTTP/1.1 301 Moved Permanently
Retry-After: 0
$ curl -I -X GET http://www.ft.comHTTP/1.1 301 Moved Permanently
Retry-After: 0

But why does redirect to, would it not be one less redirect to send users straight to

The reason is that you want users to have HSTS policies set for both hosts, which would not be the case if users never visited

We actually supply two different Strict-Transport-Security headers, depending on the host.

$ curl -I -X GET https://ft.comHTTP/1.1 200 OK
Strict-Transport-Security: max-age=63072000; preload
$ curl -I -X GET https://www.ft.comHTTP/1.1 200 OK
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Pulling apart the headers, there are a few directives we define.

max-age states how long a user agent should respect the policy. Each new response including this header will reset this time back to the max-age value.

includeSubDomains means this host, and all subdomains of this host should be covered by the HSTS policy.

Finally the preload directive is as we described earlier.

The difference is that we don’t include includeSubDomains for requests to This is very intentional.

There are a number of legacy systems at the FT using subdomains that don’t support secure connections. There are also a number of other subdomains that are secure, but the teams running them may not be prepared for HSTS.

This combination of headers and directives means that we limit this policy to only and and all its subdomains (i.e. *, while still allowing insecure connections to several * subdomains.

The hurdles

We started launching the new site long before October 2016, but have only started to declare HSTS support since January 2018. Legacy systems running on were the main hurdles we had to work with.

Biggest of them all was the old site, in launching we gradually rolled out the the current to a percentage of users until we hit 100% in October 2016. Until then we needed to support insecure connections for the previous

We also had a number of systems running off under various paths that didn’t support secure connections. One such example was the previous live blogs system, which was updated to work over secure connections.

For your typical site, you cannot get onto the preload list unless all requirements are met. However, we don’t actually conform. After sending a kind email to the HSTS project asking for an exception to be made for, we can now protect our users while working on the long tail of subdomains.

What’s next?

Serving the includeSubDomains directive on requests to is the ultimate goal.

Our user facing sub-sites like and will be our next focus to start protecting.

Longer term, rolling out HSTS to the many hundreds of domains that belong to FT Group will not be trivial.

Making it the default for new domains, however, is a no-brainer.