What Is HSTS? Complete Guide to HTTP Strict Transport Security (2026)

Why a Server-Side Redirect Is Not Enough

Most developers assume that a 301 redirect from http://example.com to https://example.com is sufficient. It is not. The redirect only fires after the browser sends an unencrypted HTTP request — which means the request travels over the network in plaintext first. An attacker positioned between the user and the server (a coffee-shop Wi-Fi router, a malicious ISP, a compromised proxy) can intercept that first request, respond with a fake HTTP page, and the user never sees HTTPS at all.

HSTS solves this by moving the enforcement to the browser. After the first legitimate HTTPS visit — where the browser receives the Strict-Transport-Securityheader — every subsequent navigation to that domain skips the HTTP request entirely. The browser upgrades to HTTPS internally, before any packet leaves the device. RFC 6797 §14.6 explicitly acknowledges the "Bootstrap MITM Vulnerability" — that the very first request to a host is unprotected — which is the canonical justification for the preload list.

According to Google's HTTPS Transparency Report, the share of pages loaded in Chrome over HTTPS has been above 90% across most countries for years — but a significant portion of those sites still lack HSTS, meaning the first visit remains vulnerable to SSL stripping on untrusted networks.

The Strict-Transport-Security Header: Full Syntax

The header has one required directive and two important optional ones:

Strict-Transport-Security: max-age=<seconds>[; includeSubDomains][; preload]

max-age

Tells the browser how many seconds to cache the HSTS policy. During this window, the browser will refuse HTTP connections to the domain and automatically use HTTPS. The OWASP HSTS Cheat Sheet recommends a staged rollout: start with max-age=86400 (1 day) to allow rollback if something breaks, then increase to max-age=63072000 (2 years) once the deployment is proven. The max-age=31536000 (1 year) value is the minimum required for preload list inclusion.

# Initial rollout — short max-age allows quick rollback
Strict-Transport-Security: max-age=86400; includeSubDomains

# Established deployment — OWASP recommended
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

includeSubDomains

Extends the HSTS policy to every subdomain of the host. Without this directive, an attacker can downgrade a request to api.example.com or static.example.com even though example.com is protected. Always include this directive unless a subdomain legitimately cannot serve HTTPS.

preload

Signals that you want the domain included in the browser preload list. This directive alone is not enough — you must also submit the domain at hstspreload.org. Once accepted, the domain is hardcoded into Chrome, Firefox, Safari, and Edge, so the very first visit is also protected.

# Recommended production HSTS header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS Preload List: How to Get On It (and Off It)

The preload list is maintained by the Chromium project and adopted by Chrome, Firefox, Safari, and Edge. Submitting your domain means that even users who have never visited your site before will connect over HTTPS from the very first request. Note that hstspreload.orgexplicitly warns that preloading has "permanent consequences" — removal can take months to propagate via browser releases — and is not recommended for sites that may not commit to HTTPS permanently.

Requirements for preload eligibility

• Serve a valid HTTPS certificate on the root domain.
• Redirect all HTTP traffic to HTTPS (port 80 → 443).
• All subdomains must serve HTTPS (the includeSubDomains directive is mandatory).
• max-age must be at least 31,536,000 seconds (one year).
• The preload directive must be present.

How to submit

Go to hstspreload.org, enter your domain, and verify it passes all checks. Submission is free. Propagation to stable Chrome typically takes 2–4 months, as it ships with a browser release.

Removing a domain from the preload list

Removal is intentionally slow — it also takes months and a browser release to propagate. If you remove HTTPS from a domain that is on the preload list, users on browsers with the old list will see connection errors. Never submit a domain unless you are committed to serving HTTPS on it permanently.

Common HSTS Mistakes

1. Sending HSTS over HTTP

Browsers ignore the Strict-Transport-Security header if it arrives over an HTTP connection. The header must only be sent on HTTPS responses. An attacker serving a fake HTTP page cannot inject a valid HSTS policy.

2. Setting max-age too low

A max-age of 300 seconds (5 minutes) means the browser forgets the policy after every few minutes of inactivity. Use at least 31,536,000 (one year). While testing, you can start with a lower value — but increase it before going to production.

3. Omitting includeSubDomains

Protecting example.com without includeSubDomains leaves every subdomain exposed. An attacker can still perform SSL stripping on mail.example.com or inject a session cookie via a downgraded subdomain (a subdomain cookie injection attack).

4. Submitting to preload before all subdomains are HTTPS-ready

Once on the preload list, every subdomain must serve HTTPS or users will see errors. Audit all subdomains with a crawler before submitting. Use Google Search Console coverage reports to check for HTTP-only pages.

5. Not testing with Chrome DevTools

Open Chrome DevTools → Security panel on your domain. It shows whether HSTS is active, when the policy expires, and whether the preload list is in effect. This is the fastest way to verify the header is working correctly.

HSTS vs. Other HTTPS Enforcement Methods

How to Verify Your HSTS Header

• Chrome DevTools → Security panel — shows HSTS status, expiry, and whether preload is active for the current domain.
• curl on the command line:

  curl -sI https://example.com | grep -i strict

• Greadme deep scan — audits your HTTP security headers including HSTS presence, max-age value, and includeSubDomains coverage across the full page.
• hstspreload.org checker — confirms whether your domain is on the preload list or eligible for submission.

FAQ

Does HSTS replace HTTPS?

No. HSTS enforces HTTPS — it does not create it. You still need a valid TLS certificate and an HTTPS server. HSTS simply tells browsers to always use HTTPS for your domain, preventing any accidental or forced HTTP connections.

What happens if my HTTPS certificate expires while HSTS is active?

Users will see a hard browser error they cannot bypass — HSTS removes the ability to click through certificate warnings. Keep automated certificate renewal (e.g., Certbot with a systemd timer or Let's Encrypt's auto-renew) working at all times.

Can I set HSTS on a subdomain only?

Yes. The header is per-host. You can set Strict-Transport-Security on app.example.com without affecting example.com, and you can omit includeSubDomains so it does not cascade further. But for maximum protection, setting HSTS on the root domain with includeSubDomains is the recommended approach.

Does a missing HSTS header affect my site's audit score?

Yes. Web performance auditing tools flag the absence of a valid HSTS header as a Best Practices issue. The check looks for the header presence, a sufficient max-age, and the includeSubDomains directive. A missing or weak HSTS header will lower your Best Practices score in any security audit.

Does HSTS affect SEO?

Indirectly, yes. Google confirmed HTTPS as a ranking signal in 2014. HSTS ensures all traffic reaches your HTTPS pages reliably — preventing redirect chains that can dilute link equity and eliminating HTTP versions of your pages that could create duplicate-content issues.

What is the TOFU problem with HSTS?

TOFU stands for Trust On First Use. The HSTS header can only be delivered over a valid HTTPS connection — which means the very first visit to a domain (before the browser has cached the policy) is still vulnerable to SSL stripping. The HSTS preload list solves TOFU by hardcoding the policy into the browser before any user visits the domain.

Does HSTS protect against all man-in-the-middle attacks?

HSTS protects against SSL stripping and HTTP downgrade attacks. It does not protect against attacks that compromise the TLS layer itself — for example, a fraudulent certificate issued by a misbehaving certificate authority. The deployed mitigation for CA compromise is Certificate Transparency (RFC 9162), which is mandatory for publicly-trusted certificates in modern browsers.

What does NIST say about HSTS?

NIST Special Publication 800-52 Revision 2 (August 2019), which provides guidelines for federal TLS deployments, recommends HSTS as part of a hardened HTTPS configuration. CISA Binding Operational Directive 18-01 makes HSTS mandatory across U.S. federal civilian executive branch agencies.