Why HTTP to HTTPS Redirects Fall Short: Risks of Exposed Requests and the Role of HSTS Preload

A common audit finding is that an internal service still answers over plain HTTP. Adding a redirect to HTTPS produces a 301 response and closes the ticket. Several weeks later, closer inspection reveals that the redirected request is a complete HTTP transaction containing the full path, query string, and Cookie header.

Who Still Sends Plaintext Requests

Contemporary browsers no longer initiate connections over HTTP by default. Chrome has inserted https:// since version 90 and strengthened the behavior in 115; Firefox and Safari follow similar logic. The first request is therefore sent over HTTPS, falling back to HTTP only when HTTPS fails.

Plaintext requests still originate from several sources: the HTTPS-fallback path itself, hard-coded http:// links in email, documentation, or bookmarks, non-browser clients such as curl and scripts, embedded web views, older devices, and long-forgotten integrations.

What Travels in the Open

The exposed request reveals the complete URL path, query parameters, session cookies without the Secure flag, and the mere fact of the connection. An on-path attacker can read this data or substitute a malicious response before TLS negotiation starts.

HSTS Closes Subsequent Visits

The Strict-Transport-Security header tells the browser to contact the host exclusively over HTTPS for the duration specified by max-age. When includeSubDomains is present, the rule applies to every subdomain. The header arrives only after a successful HTTPS response, leaving the very first visit from a new client or after cache clearance unprotected.

Preload Eliminates the First Visit

Domains listed in the HSTS preload list ship with the rule already present inside the browser binary. Entry requires a valid certificate, a max-age of at least one year, includeSubDomains, the preload directive, and a direct redirect from port 80 to HTTPS on the same host. Removal from the list takes months because the change propagates only with browser updates.

Practical Recommendations

Before enabling preload, confirm that every subdomain, including forgotten internal hosts, supports HTTPS. Test with a short max-age, then raise it gradually. Add the Secure flag to all cookies together with HttpOnly and SameSite. Replace multi-step redirects with a single jump from http://example.com directly to https://example.com. Replace any http:// links in documentation or email with https:// equivalents.

Neither HSTS nor preload protects against domain impersonation or clients that ignore the header. The only remaining defense for such clients is to ensure that http:// addresses are never published anywhere.