HSTS: Beyond SSL - Preventing Downgrade Attacks

HSTS is what makes your browser refuse to even try talking to a website over plain HTTP if it’s ever seen it securely before.

Let’s see this in action. Imagine you’ve just visited https://example.com. Your browser, if it’s seen example.com with HSTS enabled, has received a special instruction.

Here’s what that instruction looks like in a real HTTP response header:

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

• max-age=31536000: This tells the browser to remember this rule for one year (31,536,000 seconds).
• includeSubDomains: This extends the rule to all subdomains of example.com (like blog.example.com or api.example.com).
• preload: This is a special directive that allows example.com to be included in a browser’s built-in HSTS preload list. This means the browser knows to enforce HSTS even before the first secure visit.

So, what does this mean for you, the user?

The next time you type http://example.com into your address bar, or if a link on another site points to http://example.com, your browser won’t even send that initial, insecure HTTP request. It will immediately, and silently, upgrade the request to https://example.com before it hits the network.

This prevents a whole class of attacks where an attacker intercepts your initial HTTP request and redirects you to a malicious site (a "man-in-the-middle" attack) or serves you a compromised version of the page. HSTS effectively says, "Nope, you only talk to this site over TLS/SSL, and I’ll enforce that for you."

The problem HSTS solves is the "SSL stripping" attack. Without HSTS, a malicious actor could intercept your connection and downgrade your HTTPS request to HTTP. They could then serve you a fake login page or malware, all while your browser might show a padlock icon (if they’ve managed to trick the browser into thinking it’s secure). HSTS eliminates this possibility by making the browser incapable of initiating an HTTP connection to a site it knows should be HTTPS.

The core components you control are the max-age, includeSubDomains, and the decision to submit to the preload list.

• max-age is crucial. A short max-age means the browser will eventually forget the rule and revert to allowing HTTP requests. A common starting point for new HSTS deployments is 6 months (max-age=15768000), but once you’re confident, a year or more is standard.
• includeSubDomains is powerful but requires careful planning. If you have any subdomains that don’t support HTTPS, enabling this will make them inaccessible. Ensure all your subdomains are ready for HTTPS before flipping this switch.
• The preload directive is managed by browser vendors (like Google, Mozilla, Apple). You submit your domain to a central list, and if accepted, browsers ship with your domain already marked for HSTS. This protects users on their very first visit.

The mental model is that HSTS is a browser-side policy enforced locally. The server just announces the policy via the Strict-Transport-Security header. The browser then stores this policy and uses it for future connections. It’s not something that happens at the load balancer or the web server itself in terms of enforcement; they just serve the header. The browser does the heavy lifting.

The surprising thing is how the preload list works. It’s not an opt-in from the server that browsers just magically respect after one visit. Instead, it’s a curated, distributed list that browser vendors update in their code. You submit your domain, it gets reviewed, and then it’s baked into future browser releases. This means that even a brand new user, on a brand new browser installation, who has never visited your site before, will be protected by HSTS if your domain is on the preload list.

One common point of confusion is that HSTS only works if the user has already visited your site securely over HTTPS at least once. If their first visit is over HTTP, an attacker can still perform an SSL stripping attack. This is precisely why the preload directive exists – to solve that initial connection problem.

The next step after implementing HSTS is to understand certificate transparency logs and how they relate to certificate issuance and revocation.