HSTS Doesn't Protect the First Connection — Why the Preload List Exists and How to Use It Safely

The HTTP Strict-Transport-Security header sent by a web server instructs browsers to only contact that domain over HTTPS for a specified period — but if the header is ever sent over HTTP, it's ignored, and the very first connection to the site (before any HTTPS redirect) remains vulnerable to a downgrade attack

The previous articles on this site covered HTTP header basics, security headers, HTTP caching, CORS, Cache-Control directives, and HTTP/2 and HTTP/3. This article addresses HSTS (HTTP Strict Transport Security) in depth — the specific implementation details that determine whether HSTS actually protects against real attacks, and the HSTS preload list that eliminates the first-connection vulnerability.

What HSTS actually does and doesn't do

HSTS is an HTTP response header that instructs browsers:

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

What HSTS does:

• After receiving this header over a valid HTTPS connection, the browser marks the domain as "HSTS host" for the duration of max-age (in seconds)
• For all subsequent connections to this domain during the max-age period, the browser automatically upgrades HTTP requests to HTTPS before connecting — it never sends an HTTP request at all
• If an HTTPS connection can't be established (certificate error), the browser shows an error and refuses to let the user proceed (unlike for non-HSTS sites where users can click through certificate warnings)

What HSTS doesn't do:

• Protect the very first connection to a domain (before the browser has seen the HSTS header)
• Protect against DNS attacks that redirect traffic before any HTTP/HTTPS connection is made
• Protect users who visit via a link that explicitly specifies HTTP and the browser hasn't previously established the HSTS policy for that domain

The trust-on-first-use problem and HSTS preload

The first connection vulnerability is called the "trust-on-first-use" (TOFU) problem:

1. User has never visited https://example.com before
2. They navigate to http://example.com
3. Before HSTS kicks in, the browser sends an HTTP request
4. An attacker can intercept this first HTTP request and downgrade the connection

HSTS preload solves this by baking HSTS information directly into browsers, so the browser knows to use HTTPS before ever visiting the domain:

The preload list: a list of domains that browsers ship with as "always use HTTPS." Maintained by Google (hstspreload.org), it's included in Chrome, Firefox, Safari, Edge, and other major browsers.

Requirements for preload submission:

1. Valid HTTPS on the domain
2. HSTS header with max-age of at least 31,536,000 (1 year)
3. includeSubDomains directive
4. preload directive in the header
5. All subdomains must also be HTTPS

The caveat: once a domain is on the preload list, removing it requires waiting for the next browser release cycle (months) and a removal request. This is a one-way commitment — don't add a domain to the preload list unless you're confident in maintaining HTTPS permanently.

includeSubDomains: the scope of the commitment

The includeSubDomains directive extends HSTS to all subdomains of the domain:

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

After receiving this from example.com, the browser will also enforce HTTPS-only for admin.example.com, mail.example.com, staging.example.com, and any other subdomain.

The operational risk: if any subdomain doesn't have valid HTTPS configured, users will be unable to access it entirely (the browser won't fall back to HTTP, it'll just fail). Before adding includeSubDomains, verify that every subdomain of the domain has valid HTTPS.

Discovery of unexpected subdomains: Certificate Transparency logs (crt.sh) show all certificates issued for a domain and its subdomains — checking these before enabling includeSubDomains reveals subdomains you may not have known about.

The max-age value: how long the HSTS policy persists

max-age is in seconds:

• 31,536,000 = 365 days (1 year)
• 63,072,000 = 730 days (2 years) — common recommendation
• 86,400 = 1 day — useful for testing
• The preload submission requirement is min 31,536,000

The max-age countdown resets on each HTTPS visit — the browser sees the header again and the timer restarts. For a site visited regularly, the HSTS policy is effectively permanent.

Removing HSTS: to intentionally remove HSTS from a domain (e.g., you're decommissioning HTTPS), serve the header with max-age=0 over HTTPS, which clears the stored HSTS policy in the browser. This only works for users who visit the site after this change — browsers that haven't received the max-age=0 header maintain their previously cached HSTS policy.

HSTS and mixed content: the interaction

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets) from HTTP URLs. HSTS interacts with mixed content in a specific way:

For domains in the HSTS cache: if an HTTPS page tries to load http://example.com/image.jpg and example.com is in the HSTS cache, the browser upgrades the request to HTTPS automatically. The mixed content warning disappears because the browser upgraded the HTTP request.

For domains NOT in the HSTS cache: the browser may block the HTTP resource (active mixed content like scripts is blocked in modern browsers; passive mixed content like images may display with a warning).

The practical implication: sites that have HSTS enabled may appear to have fewer mixed content issues because their own domain's HTTP links are automatically upgraded — but third-party HTTP resources from non-HSTS domains still generate mixed content issues.

How to use the HTTP Headers Checker on sadiqbd.com

1. Check HSTS presence and parameters: verify the Strict-Transport-Security header is present on HTTPS responses, check the max-age value, and confirm includeSubDomains is present if subdomains are all HTTPS
2. Verify security headers audit: beyond HSTS, check for X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and Content-Security-Policy — each addresses different attack vectors
3. Cache-Control audit: check that sensitive pages (account settings, payment flows) have Cache-Control: no-store to prevent cached copies appearing in shared browsers

Frequently Asked Questions

If HSTS is applied, does that mean my site is immune to SSL stripping attacks? For returning visitors, yes — for first-time visitors, no (unless the domain is preloaded). SSL stripping attacks intercept the initial HTTP request and downgrade the connection before HTTPS is established. For a site with HSTS that the user has visited before, the browser never sends the initial HTTP request — it internally rewrites http:// to https:// before connecting. For a site on the preload list, this protection extends to users who have never visited before. For a site with HSTS but not on the preload list, the first visit is still potentially vulnerable — which is why the preload list exists and security-critical sites (banks, government services) should prioritise getting on it.

Is the HTTP Headers Checker free? Yes — completely free, no sign-up required.

Try the HTTP Headers Checker free at sadiqbd.com — inspect the complete HTTP response headers for any URL instantly.