HSTS
HTTP Strict Transport Security
A security policy header that instructs browsers to connect to a site exclusively over HTTPS for a set period, eliminating the window where a downgrade attack could intercept the first plaintext request.
HSTS is delivered in an HTTP response header: Strict-Transport-Security: max-age=31536000; includeSubDomains. Once a browser receives this header, it remembers for max-age seconds that the site must only be visited over HTTPS. Any future navigation to the HTTP version is silently upgraded to HTTPS by the browser — the HTTP request never leaves the machine.
Why an HTTP redirect to HTTPS alone is not enough
A common misconception is that redirecting http:// to https:// at the server is sufficient security. It is not. The very first HTTP request — before the redirect response arrives — travels in plaintext over the network. An attacker performing an SSL stripping attack can intercept that first request, strip the redirect, and serve a fake HTTP version of the site. The user sees no padlock, but may not notice. HSTS eliminates this window entirely: the browser never sends the HTTP request in the first place, so there is nothing for the attacker to intercept.
HSTS header syntax and parameters
| Directive | Effect | Recommended value |
|---|---|---|
max-age=N | Remember HTTPS-only rule for N seconds | 31536000 (1 year) |
includeSubDomains | Apply rule to all subdomains | Include if all subdomains support HTTPS |
preload | Signal intent to join browser preload list | Only add when ready for permanent HTTPS |
A minimal HSTS header for a new deployment might start with a short max-age (e.g., 300 seconds) to test for problems, then increase to 31536000 once HTTPS is confirmed stable. The preload directive does nothing by itself — it signals intent; the domain owner must separately submit to hstspreload.org.
How HSTS defeats SSL stripping attacks
SSL stripping, popularised by the sslstrip tool, works by sitting between a client and server, downgrading the client's HTTPS connection to HTTP while maintaining an HTTPS connection to the server. The attacker sees all plaintext traffic. HSTS defeats this because a browser with a cached HSTS entry for the domain will refuse to send any HTTP request to it — the connection attempt is upgraded to HTTPS internally, and if it fails (e.g., due to an invalid certificate), the browser shows an error rather than falling back to HTTP.
HSTS preload list
Even HSTS has one remaining vulnerability: the very first visit, before the browser has received the HSTS header. The HSTS preload list closes this gap — browsers (Chrome, Firefox, Safari, Edge) ship with a hardcoded list of domains that must always use HTTPS, before any visit has ever occurred. Domains submit at hstspreload.org; requirements include a valid HTTPS certificate, HTTP-to-HTTPS redirects on the root domain and all subdomains, a max-age of at least 1 year, the includeSubDomains directive, and the preload directive in the header.
Preload list inclusion is effectively permanent on practical timescales: removal requires re-submitting a removal request, then waiting for a browser release to ship the updated list — a process that can take months. A domain on the preload list that loses its HTTPS certificate becomes completely inaccessible in all major browsers until the certificate is restored.
HSTS in development environments
Local development servers accessed over HTTP break if their domain has HSTS cached in the browser. The workaround in Chrome is chrome://net-internals/#hsts — enter the domain and click "Delete" to remove the cached HSTS entry. Firefox has an equivalent in about:config by searching for network.stricttransportsecurity.preloadlist. Using localhost or .local domains for development avoids the problem entirely, as these are exempt from HSTS by browser policy.
HSTS vs HPKP
HPKP (HTTP Public Key Pinning) was a related security header that told browsers to only accept specific TLS certificate public keys for a domain. It was deprecated and removed from all major browsers by 2019. The problem: a single misconfiguration or key loss could permanently brick a domain — browsers would refuse all connections for the pinning duration with no override. HSTS carries the same operational risk via the preload list, but to a lesser degree because certificate rotation is routine and well-understood. HPKP was simply too dangerous for most operators to use safely.
Frequently Asked Questions
How does HSTS protect against downgrade attacks?
Without HSTS, an attacker can intercept the initial HTTP request before the redirect to HTTPS. HSTS tells the browser to never send an HTTP request at all — it upgrades internally before any network traffic, eliminating the attack window.
What is the HSTS preload list?
A list hardcoded into browsers of domains that must always use HTTPS — protecting even the very first visit. Domains apply at hstspreload.org. Once listed, removal requires re-submission and a browser release cycle that can take months.
Can HSTS cause issues accessing websites?
Yes — if a site with HSTS active lets its TLS certificate expire or reverts to HTTP, browsers refuse to load it for the entire max-age duration. Clearing HSTS state at chrome://net-internals/#hsts (Chrome) is the immediate workaround for a cached entry, but preload-listed domains cannot be overridden this way.