HSTS Preload: HTTPS Lock-In Explained

HSTS preloading is how browsers are tricked into always using HTTPS for your domain, even on the very first visit.

Let’s see it in action. Imagine you own example.com. Normally, when someone types http://example.com into their browser, the browser makes an HTTP request. Your server then responds with a redirect to https://example.com. This first HTTP request is a window of vulnerability. An attacker could intercept it and redirect the user to a malicious site without them ever seeing your legitimate HTTPS version.

Here’s how HSTS, and specifically preloading, closes that window.

First, your web server needs to tell the browser to always use HTTPS for your domain. It does this with a special HTTP header called Strict-Transport-Security. When your server responds to a legitimate HTTPS request (say, https://example.com), it includes this header:

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

Let’s break this down:

• max-age=31536000: This tells the browser to remember to always use HTTPS for example.com for one year (31,536,000 seconds).
• includeSubDomains: This extends the rule to all subdomains of example.com (like www.example.com, api.example.com, etc.).
• preload: This is the magic part for preloading. It’s a signal that you want your domain to be included in browser preload lists.

When a browser sees the preload directive, it doesn’t just remember the rule for future visits. It also sends this information to a central list maintained by Google, called the HTTP Strict Transport Security (HSTS) Preload List. This list is then compiled into browsers (Chrome, Firefox, Safari, Edge, etc.) during their updates.

So, what does preloading actually do? It means that even before a user ever visits example.com for the first time, their browser already knows to use HTTPS. The browser consults its local, built-in preload list. If example.com is on that list, the browser will automatically convert any HTTP request to https:// before it even sends the request out. This completely eliminates the vulnerability of the initial HTTP request.

The HSTS Preload List is a curated list of domains that have explicitly opted in. To get your domain added, you need to:

1. Serve a valid HTTPS certificate.
2. Redirect all HTTP traffic to HTTPS.
3. Serve the Strict-Transport-Security header with max-age of at least 31536000 seconds (1 year), and ideally includeSubDomains.
4. Submit your domain to the preload list submission site (e.g., hstspreload.org).

Once submitted and verified, your domain will be included in the next browser version update. The process can take a few weeks to a few months depending on the browser release cycles.

The most surprising thing about HSTS preloading is that it fundamentally changes how the browser initiates connections for your domain. Instead of relying on your server to tell it to use HTTPS (via a redirect), the browser already knows and enforces it at the network stack level, before DNS lookups even happen for HTTP. This is why it protects against the very first connection from an attacker who might be impersonating your site over HTTP.

When you add includeSubDomains to your HSTS header, you’re telling the browser to enforce HTTPS for every subdomain. This means mail.example.com, blog.example.com, and any other subdomain you might have will also be forced over HTTPS. If any of those subdomains are not configured for HTTPS, they will become inaccessible when the HSTS policy is active.

The next hurdle you’ll face after successfully preloading your domain is managing certificate renewals and ensuring all your subdomains are properly configured for HTTPS.