What Is HSTS? HTTP Strict Transport Security Explained

Published December 21, 2025 · 7 min read

What Is HSTS? HTTP Strict Transport Security Explained

HSTS is one of those security headers that sounds complicated but does something pretty simple: it tells browsers "never connect to my site over plain HTTP, ever." Once a browser sees this header, it will automatically upgrade any http:// links to https:// and flat-out refuse to connect if HTTPS isn't available.

Why Bother With HSTS?

Here's the scenario HSTS prevents. You're at a coffee shop. Someone on the same wifi intercepts your first request to your bank's website - the one that goes out over HTTP before the redirect to HTTPS happens. They show you a fake login page. You type your password. Game over.

With HSTS, that first HTTP request never happens. Your browser already knows to use HTTPS because it remembered from last time. No window for interception.

It's not a theoretical attack either. Tools like sslstrip have been doing this since 2009.

How It Works

You add one header to your HTTPS responses:

\\\

\\\

Breaking that down:

Setting It Up

\\\

\\\

\\\

\\\

The Preload List

So HSTS has one weakness: the very first visit. If someone's never been to your site, their browser doesn't know to use HTTPS yet.

The preload list fixes this. It's a list of HSTS sites that ships with Chrome, Firefox, Safari, and Edge. If you're on the list, browsers use HTTPS from the very first connection - no prior visit needed.

Submit at hstspreload.org. But read the warning first.

Seriously, Read This Before Preloading

Once you're on the preload list, getting off takes months. You have to submit a removal request, then wait for it to propagate through browser updates. If you mess up your HTTPS setup while preloaded, your site is completely inaccessible. No bypass button. No "proceed anyway." Just broken.

I've seen people preload before they were ready, then realize they have a subdomain that doesn't support HTTPS. Suddenly internal-tool.company.com is unreachable and there's no quick fix.

Test everything first. Start with a short max-age (like 300 seconds). Make sure every single subdomain works over HTTPS. Then consider preloading.

Mistakes I've Seen

Start with 5 minutes. Then a day. Then a week. Then a year. Gives you time to catch problems.

If you add includeSubDomains but dev.yoursite.com doesn't have HTTPS, everyone who visits your main site gets locked out of dev.

This isn't a "set it and forget it" thing. It's a commitment. Make sure you're ready.

Frequently Asked Questions

However long max-age says. Every time someone visits, the timer resets. If they don't visit for longer than max-age, their browser forgets and you're back to square one.

Nope. Unlike certificate warnings where there's a hidden "proceed anyway" button, HSTS is absolute. Browser won't let you through.

Your site is completely unreachable until you fix the certificate. No workaround. This is why certificate monitoring matters - if you have HSTS, an expired cert isn't just a warning, it's an outage.

Yes - set max-age=0 and browsers will forget. But if you preloaded, you have to wait for browser updates to remove you from the list. Could be 6+ months.