Remediation
HTTPS should be enforced across the entire application, and every cookie carrying session state should be marked Secure so the browser does not send it over an unencrypted HTTP connection.
User request
↓
HTTPS only
↓
Encrypted connection
↓
Session cookie sent only with HTTPS requests
↓
✓ Network observers cannot read the session credential in transit
This protects against one of the most direct forms of session hijacking: an attacker observing a session cookie as it travels across an unencrypted network connection.
However, simply configuring an application to redirect HTTP requests to HTTPS leaves an important gap.
The First-Request Problem:
An HTTP-to-HTTPS redirect happens after the browser has already made an HTTP request.
Without additional protection, a user who types:
http://example.com
may initially send:
Browser
↓
HTTP request (unencrypted)
↓
Server responds:
301 / 302 → https://example.com
Under normal conditions, the browser follows the redirect and continues over HTTPS.
But an active network attacker positioned between the browser and server can interfere before that HTTPS connection is established.
Victim requests:
http://example.com
↓
Unencrypted request crosses network
↓
Active network attacker intercepts
↓
Attacker can attempt to prevent or modify the HTTPS upgrade
↓
SSL-stripping or downgrade attack
This is the gap that HTTP Strict Transport Security (HSTS) is designed to close.
HSTS:
The server can send a Strict-Transport-Security response header over a valid HTTPS connection.
For example:
Strict-Transport-Security: max-age=31536000; includeSubDomains
This tells the browser:
"This domain must be accessed using HTTPS for the next year."
After the browser has received and stored this policy, even a request explicitly made as:
http://example.com
is internally upgraded by the browser before any HTTP request is sent.
User enters:
http://example.com
↓
Browser checks stored HSTS policy
↓
Browser rewrites internally to: https://example.com
↓
First network request is already encrypted
There is no HTTP request available for a network attacker to intercept and downgrade.
The policy remains active for the duration specified by max-age.
A long lifetime—commonly one year—is often used once the application is confident that HTTPS is permanently available.
includeSubDomains:
The optional includeSubDomains directive extends the HSTS policy beyond the exact host.
HSTS policy for:
example.com
+
includeSubDomains
↓
Also applies to:
app.example.com
admin.example.com
api.example.com
other.example.com
This can prevent a weaker or forgotten HTTP-enabled subdomain from becoming a downgrade path.
However, it should only be enabled when the organization is confident that the relevant subdomains can safely support HTTPS. Once browsers have stored the policy, an HTTP-only subdomain covered by includeSubDomains may become inaccessible to those users.
The First-Visit Gap:
Standard HSTS still has one unavoidable limitation.
A browser cannot enforce an HSTS policy for a domain it has never successfully received an HSTS policy from.
First-ever visit
↓
Browser has no stored HSTS rule
↓
Initial HTTP request may still occur
↓
Potential downgrade opportunity
The HSTS preload mechanism addresses this problem.
Domains included in browser-maintained HSTS preload lists are distributed with the browser itself. The browser therefore already knows, before making its first request, that the domain must use HTTPS.
User's first-ever visit
↓
Browser already knows: example.com = HTTPS only
↓
http://example.com
↓
Internally rewritten to: https://example.com
↓
✓ No initial HTTP request
Preloading should be treated as a deliberate and long-term commitment. Before pursuing it, HTTPS should be fully and permanently deployed, and the domain's configuration should satisfy the preload requirements. Once a domain is included, removing that protection is not immediate because browser updates and preload-list changes take time to propagate.
The complete transport-security model is therefore:
HTTPS everywhere
+
Secure session cookies
+
HTTP → HTTPS redirect for compatibility
+
HSTS to prevent downgrade after the policy is known
+
HSTS preload to close the first-visit gap
↓
✓ Session credentials protected against plaintext network transport
and common downgrade attacks
The core principle is:
An HTTP redirect upgrades a request after HTTP has already been attempted. HSTS prevents the browser from attempting HTTP in the first place once the policy is known. Preloading extends that protection even to the browser's first visit.