Insights › Security

HSTS: the header that makes HTTPS stick

Without HSTS, the first visit to your domain goes over HTTP before the redirect to HTTPS kicks in — and that first request is unprotected. HSTS tells the browser to go straight to HTTPS on every future visit. Here's what it is, what the values mean, and why a redirect alone isn't enough.

Aug 8, 2026 · 5 min read

The short version

When someone types yourapp.com into the address bar, the browser sends an HTTP request first. Your server redirects it to HTTPS — but that first HTTP request already went out unprotected. HSTS fixes this: it tells the browser "always use HTTPS for this domain for the next year, don't even try HTTP." After the first visit, every request goes straight to HTTPS. Without HSTS, every first visit of the day starts with an unprotected request.

What the header looks like

HTTP response headertxt

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

What each value means

`max-age` — How long (in seconds) the browser should remember to use HTTPS. 31536000 is one year, which is the minimum for the HSTS preload list. Anything shorter is a token gesture — set it to at least a year.
`includeSubDomains` — Extends the rule to every subdomain of your domain. Without it, api.yourapp.com and docs.yourapp.com can still be visited over HTTP. This should almost always be set.
`preload` — Opts your domain into the HSTS preload list, a hardcoded list shipped inside every major browser. Once on the list, even the very first visit goes straight to HTTPS — no unprotected first request. This is irreversible in practice (removal from the list takes months), so only add it once you're confident HTTPS is permanent.

Why a redirect alone isn't enough

A 301 redirect from HTTP to HTTPS protects the second request and beyond, but the first request is already in the air. An attacker on the same network (public Wi-Fi, compromised router) can intercept that first HTTP request before the redirect happens — a classic SSL stripping attack. They serve a fake version of your site over HTTP, and the browser never gets the redirect.

HSTS closes this window: after the first visit, the browser remembers to use HTTPS directly. The preload directive closes even the first-visit window by shipping the rule inside the browser itself.

The three most common HSTS mistakes

Mistake	Result	Fix
No HSTS header	Every first visit goes over HTTP — SSL-strippable	Add the header with max-age ≥ 31536000
max-age is too short (e.g. 86400 = 1 day)	The browser forgets the rule every 24 hours — most visits are unprotected	Set max-age to at least 31536000 (one year)
includeSubDomains missing	Subdomains can be visited over HTTP, bypassing the protection	Add includeSubDomains

How to verify

1
curl the live HTTPS URL
curl -I https://yourapp.com | grep -i strict. You should see the full header with max-age, includeSubDomains, and optionally preload.
2
Check it's set on the bare domain too
The redirect from yourapp.com to www.yourapp.com should also return HSTS. Every response in the chain should set it.
3
HSTS Preload Check
Go to hstspreload.org, enter your domain. It checks whether your header meets the preload requirements and lets you submit for inclusion.

Actuant checks for the HSTS header on your deployed app, grades the max-age value (under one year = partial), and verifies includeSubDomains is present.

Keep reading

Security headers: the six your app needs and what each one protects

Security headers are HTTP response headers that tell the browser how to defend your visitors. A generated deploy sets none of them. Here are the six that matter, what each one does, and how to check they're actually being served.

Content-Security-Policy: what it protects, how to write one, and the mistake that makes it useless

A Content-Security-Policy tells the browser which scripts, styles and connections to trust — it's your primary defense against XSS. A generated app ships with none. Here's how to write one that's strong enough to matter and test it without breaking anything.