In this post I will discuss HSTS preloading and why I enrolled yoxall.me.uk onto the strict HSTS list.

What does this mean?

The first time a browser attempts to connect to a website, it defaults to standard HTTP — regardless of whether an HSTS header is set. This is because it has never visited before and does not know about the HTTP Strict Transport Security response (the TOFU — Trust On First Use — model). This means the very first request to a secure site is vulnerable to a MITM attack and could be intercepted.

Since my site is enrolled on the strict list, browsers know before ever visiting that they should use HTTPS — even on that very first request.

Pros

HTTPS enforced both server and client-side. If the server protocol is ever compromised, the client-side browser will refuse to initiate the connection and prevent further leakage.

SEO benefit. Google uses HTTPS enforcement as a ranking signal. Enforcing it at the client side via the preload list compounds the benefit.

Cons

You must be able to support HTTPS for the long term. If you ever cease support for HTTPS, users will not be able to connect — even if you remove the server-side HSTS header, because the strict list is hard-coded into the browser itself. Removal from the list is also a slow, difficult process.

Conclusion

I would much rather a user not be able to connect to my site at all than have the contents transmitted in plain text. It is for this reason that my site is strictly enforced as HTTPS-only on all modern browsers.

Note: this is not a replacement for server-side HSTS enforcement — you need both. Users on less common browsers will not have a hard-coded HSTS list, so the server-side header still matters.