TLS

Short HSTS max-age: what it really means, and how to extend it safely.

Published 2026-05-25 · Last updated 2026-05-25 · Vantyris editorial

What this means for your business

• HSTS protects against an attacker on a hostile network downgrading a returning visitor's connection from HTTPS to HTTP on the very first request of a session. Once the browser has seen a valid HSTS header from your site, it remembers to use HTTPS for the duration of max-age, even if the visitor types `http://yoursite` or follows an old bookmark.
• A short max-age (under a day) means the protection effectively isn't there for returning visitors — the browser forgets the policy almost immediately. A long max-age (one year+) plus `includeSubDomains` plus `preload` plus a submission to https://hstspreload.org gets your domain baked into Chrome / Safari / Firefox's preload list, eliminating the first-connection window entirely.
• If HTTPS is working everywhere, there's no mixed content, the certificate is valid, and the site does a 301 from HTTP to HTTPS: a short HSTS is a hardening gap, not an emergency. Treat it like 'we should clean this up' rather than 'we have an active vulnerability'. (Vantyris reflects this by marking very-short HSTS as Medium severity, anything else as Low.)

How to fix

Raise the max-age to at least six months in stages. Start at six months, watch for two weeks for any subdomain breakage, then push to one or two years. Add `includeSubDomains` only after confirming every subdomain serves HTTPS. Add `preload` and submit to hstspreload.org only after the long max-age has been stable for a couple of weeks.

1. If you're behind Cloudflare. Cloudflare dashboard → SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS). Enable HSTS. Max Age: choose 6 months to start, raise to 12 months after 1-2 weeks. Include subdomains: only check this when every subdomain serves HTTPS (catch: an old `dev.yoursite.example` that still does plain HTTP will break). Preload: only check after validation, then submit your domain at https://hstspreload.org.
2. If you run Nginx directly. Add inside your server block (or in a shared snippet): ``` add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; ``` The `always` directive ensures the header is sent on error responses too (some Nginx configurations silently drop headers on 4xx / 5xx without it). After 1-2 weeks, increase to `max-age=63072000; includeSubDomains; preload` and submit.
3. If you run Apache directly. Add in your virtual host or `.htaccess`: ``` Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" ``` Same staging plan: hold for 1-2 weeks, then bump to `max-age=63072000; includeSubDomains; preload`.
4. Submit to the preload list (optional but recommended). Visit https://hstspreload.org. Enter your domain. The form checks: HTTPS works on the apex and `www`, the cert is valid, HTTP redirects to HTTPS (not HTTPS-then-HTTP), HSTS max-age ≥ 63072000 (two years), `includeSubDomains` and `preload` directives are present. If all pass, submit. It takes 4-12 weeks for the domain to land in browser builds.

Owner: Your web host or developer. · Time: Cloudflare: 5 minutes per stage. Nginx / Apache: 10 minutes per stage. The 'preload' submission round-trip is weeks, not minutes.

Common gotchas

• Don't enable `includeSubDomains` without auditing every subdomain. `dev.example.com`, `staging.example.com`, and `mail.example.com` are common HTTP-only stragglers that break the moment the parent domain's HSTS forces HTTPS on them.
• HSTS preload is one-way for practical purposes. Removing your domain from the preload list takes months and during that time visitors will be hard-blocked from HTTP. Don't preload until you're certain HTTPS is permanent.
• If you run a development subdomain over plain HTTP for testing, exclude it from the parent domain's policy by using a separate hostname (`dev.your-internal-domain.example`) that isn't covered by `includeSubDomains`.
• Browsers cache the HSTS header per-host. Changing max-age in the response only takes effect when a browser receives a fresh response — existing browsers keep using the old cached policy until their stored max-age expires. The first staged change therefore takes effect immediately for new visitors and at the end of the previous max-age for returning ones.

How to verify the fix

After deploying the new header, hit your site with `curl -sI https://yoursite | grep -i strict-transport-security` and confirm the new max-age value is shown. Then open Chrome's `chrome://net-internals/#hsts`, enter your domain, click 'Query', and confirm `static_sts_observed` shows your new max-age. Run a Vantyris scan to confirm the `headers.hsts_ok` healthy signal fires.

Cyber Essentials alignment

This finding informs the following UK NCSC Cyber Essentials control areas:

• A2. Secure configuration — devices and services hardened against the inherent default vulnerabilities.

Vantyris is not a CE certifying body. The mapping above is informational.

Common follow-up questions

References

• RFC 6797 — HTTP Strict Transport Security IETF RFC
• MDN: Strict-Transport-Security MDN
• HSTS preload list submission form Vendor
• OWASP: HTTP Strict Transport Security OWASP

Related explainers

• HTTPS for small business: how to enable it in 15 minutes.