Why HTTP to HTTPS Redirects Fall Short: Risks of Exposed Requests and the Role of HSTS Preload
A simple HTTP to HTTPS redirect satisfies basic audit requirements but leaves the initial request fully exposed in plaintext. The request carries the full path, query parameters, and cookies lacking the Secure flag, allowing observers on open Wi-Fi or compromised routers to read or tamper with traffic before TLS begins. Modern browsers such as Chrome since version 90 attempt HTTPS first, yet legacy clients, explicit http:// links in emails, scripts, and failed HTTPS fallbacks continue to send unprotected requests. HSTS instructs browsers to use HTTPS after the first successful visit, yet the header itself travels over HTTPS and cannot protect the very first connection from a new device or cleared cache. Preloading embeds the rule directly in the browser, eliminating the initial plaintext request entirely, but demands includeSubDomains and a one-year max-age, making the change effectively irreversible for months. The article recommends verifying Secure flags on all cookies, ensuring single-step redirects to the same host, and testing HSTS incrementally before considering preload.
HabrSep 13, 2026Translated from Russian