---
title: HSTS Explained: forcing browsers to always use HTTPS
description: You redirect HTTP to HTTPS — but that first insecure request is still a risk. HSTS closes that gap by telling browsers to never even try HTTP. Here's how it works and how to deploy it safely.
canonical: https://watchfor.io/blog/hsts-explained
---

# HSTS Explained: forcing browsers to always use HTTPS

2025-12-20 · WatchFor Team · Security · security, web, ssl

You redirect HTTP to HTTPS — but that first insecure request is still a risk. HSTS closes that gap by telling browsers to never even try HTTP. Here's how it works and how to deploy it safely.

You've done the right thing: your site is on HTTPS, and you redirect any `http://` request to `https://`. Job done? Almost. There's a sliver of a gap — that *very first* insecure request before the redirect — and attackers can exploit it. **HSTS** is the header that closes it.

## The gap HSTS closes

Even with an HTTP-to-HTTPS [redirect](/blog/301-vs-302-redirects), the sequence has a weak moment:

1. A user types `example.com` (browsers default to `http://`).
2. That first request goes out **over plain HTTP**.
3. Your server responds with a redirect to HTTPS.

Steps 1–2 happen *unencrypted*. An attacker on the network could intercept that first request and hijack it (an "SSL stripping" attack) before the redirect ever lands. The window is small, but it's real.

## What HSTS does

**HSTS (HTTP Strict Transport Security)** is a response header that tells the browser: *"For this site, always use HTTPS — never even attempt HTTP, no matter what."*

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

Once a browser sees this, it remembers (for the `max-age` duration) to automatically convert any `http://` request for your site to `https://` **before sending it** — eliminating that insecure first request entirely.

## The directives

| Directive | Meaning |
| --- | --- |
| `max-age` | How long (seconds) the browser enforces HTTPS-only |
| `includeSubDomains` | Apply it to all subdomains too |
| `preload` | Opt into the browser preload list (HTTPS from the very first visit) |

## The preload list — powerful but careful

There's one more level: the **HSTS preload list**, baked directly into browsers. Sites on it are forced to HTTPS *even on the very first visit ever*, with no insecure request at all.

> **Preload is a commitment, not a setting.** Once your domain is on the preload list, browsers will refuse HTTP entirely — and getting *off* the list is slow. Only preload when you're certain every subdomain can do HTTPS, forever. It's powerful, but hard to reverse.

## How to deploy HSTS safely

Because HSTS is "sticky" (browsers remember it), a mistake is hard to undo. Roll it out gradually:

1. **Make sure HTTPS works everywhere first** — every page, every subdomain, valid [certificates](/blog/ssl-certificate-expiry).
2. **Start with a short `max-age`** (e.g. a few minutes/hours) to test.
3. **Increase `max-age`** to a long value (a year is common) once confident.
4. **Add `includeSubDomains`** only when *all* subdomains support HTTPS.
5. **Consider `preload`** last, and only if you're fully committed.

The danger: if you enable `includeSubDomains` but a subdomain *can't* do HTTPS, browsers will refuse to load it — and they'll keep refusing until `max-age` expires.

## A monitoring note

HSTS only helps if HTTPS keeps working. If your [certificate expires](/blog/ssl-certificate-expiry) while HSTS is active, browsers won't fall back to HTTP — they'll just **block the site entirely**, with no escape hatch. That makes [certificate monitoring](/docs/monitors/certificates) doubly important once HSTS is on.

## The bottom line

| | In one line |
| --- | --- |
| **What** | A header telling browsers to always use HTTPS for your site. |
| **Why** | Closes the insecure-first-request gap (SSL stripping). |
| **Careful with** | `includeSubDomains` and `preload` — hard to reverse. |
| **Pair with** | Rock-solid HTTPS + certificate monitoring (no fallback once on). |

HSTS is a small header with a big security payoff — it makes "always HTTPS" truly always. Just deploy it gradually and keep your certificates healthy, because once HSTS is on, there's no falling back.

Related: [How HTTPS works](/blog/how-https-works), [SSL certificate expiry](/blog/ssl-certificate-expiry), [301 vs 302 redirects](/blog/301-vs-302-redirects).

---

Canonical page: https://watchfor.io/blog/hsts-explained · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt