HSTS tells browsers to always use HTTPS when connecting to your site, even if someone types http:// or clicks an HTTP link. The browser automatically upgrades the connection.

Can HSTS be reversed?

Not easily. Once a browser receives an HSTS header, it remembers it for the duration of max-age. You can't undo it by removing the header until that time expires.

Do I need HSTS if I already redirect HTTP to HTTPS?

Yes. The redirect itself happens over HTTP, which is vulnerable to interception. HSTS prevents that first insecure request from ever happening.

What is HSTS? HTTP Strict Transport Security Explained

The short version

HSTS (HTTP Strict Transport Security) is an HTTP header that tells browsers: "Never connect to this site over plain HTTP. Always use HTTPS. No exceptions."

Once a browser sees this header, it remembers. For every future visit, it automatically upgrades HTTP requests to HTTPS before they leave the browser. No round trip needed.

Why redirects aren't enough

You might think: "I already redirect HTTP to HTTPS, so what's the problem?"

Here's the problem. That first request, the one before the redirect kicks in, happens over plain HTTP. It's unencrypted. An attacker sitting on the same Wi-Fi network (think coffee shops, airports) can intercept it and do whatever they want. This is called a man-in-the-middle attack.

HSTS eliminates that window. After the browser sees the HSTS header once, it never makes a plain HTTP request to your site again. The upgrade happens inside the browser, before any network traffic.

This is defined in RFC 6797, which specifies the full mechanism.

How to set it up

The header looks like this:

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

Let's break that down:

max-age=31536000: Remember this policy for one year (in seconds).
includeSubDomains: Apply to all subdomains too.
preload: Signal that you want to be included in the browser preload list (more on that below).

You set this header in your web server config, CDN settings, or framework middleware. Most platforms (Vercel, Netlify, Cloudflare) support custom headers.

The preload list

There's still one vulnerability: the very first visit. The browser hasn't seen the HSTS header yet, so that initial request could still be HTTP.

To fix this, browsers maintain a preload list. If your domain is on the list, browsers ship with the knowledge that your site requires HTTPS. No first visit needed.

To qualify for the preload list:

Serve a valid HTTPS certificate
Redirect HTTP to HTTPS
Include the preload directive in your HSTS header
Set max-age to at least one year
Include includeSubDomains

Submit your domain at hstspreload.org.

Common mistakes

Setting max-age too low. A value of max-age=300 (5 minutes) barely does anything. Use at least max-age=31536000 (one year). As MDN's HSTS documentation recommends, start with a shorter value to test, then increase it.

Forgetting includeSubDomains. If your API lives at api.example.com and it doesn't have HSTS, attackers can target that subdomain instead.

Not having HTTPS properly set up first. If you enable HSTS before your SSL/TLS certificate is working correctly, you'll lock users out of your site. Make sure HTTPS works perfectly before turning on HSTS.

The bottom line

HSTS is one header, one line of config, and it closes a real attack vector. There's no reason not to use it once your site runs on HTTPS.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.