HTTPS Protection Window Is Too Short

Vulnerability Explanation

The server's Strict-Transport-Security (HSTS) header is present but configured with a max-age value below one year (31,536,000 seconds). The max-age directive tells browsers how long they should enforce HTTPS-only connections for the domain. A short max-age means the browser's HSTS cache entry expires sooner, creating periodic windows — particularly for infrequent visitors — where the browser no longer enforces HTTPS and could be susceptible to a protocol downgrade or SSL-stripping attack if another vulnerability is present.

Root Cause

The max-age value was likely set conservatively during initial HSTS rollout (a reasonable practice for testing) but was never increased to a production-appropriate value. Short values are appropriate for staging environments but should be raised to at least one year before or shortly after production deployment.

Technical Impact

On its own, a short max-age does not allow direct exploitation. However, it weakens the HSTS protection window: browsers that haven't visited the site recently will not enforce HTTPS on their next connection, making them theoretically susceptible to SSL-stripping or downgrade attacks if an attacker can intercept the initial HTTP request. The risk is highest for infrequent visitors on hostile networks (e.g., public Wi-Fi).

Severity Justification

HSTS is already present and functional; this is a configuration hardening issue, not an exploitable vulnerability in isolation. The weakness only matters in combination with a network-level attacker intercepting a user's first unprotected request after the HSTS entry has expired. CVSS is not formally assigned to this class of misconfiguration.

Affected Components

• Strict-Transport-Security header — max-age < 31536000 (all web server stacks)

Remediation Steps

1. Update the Strict-Transport-Security header to set max-age to at least 31536000 (1 year). The recommended value per OWASP and MDN is 63072000 (2 years). See config examples below for Nginx, Apache, and Express.
2. Add the includeSubDomains directive if all subdomains are served over HTTPS. This extends HSTS protection to subdomains and is required for preload list eligibility.
3. Deploy and verify the updated header is returned on all HTTPS responses (not just the homepage). Check API endpoints and subdomains if applicable.
4. Optionally, submit your domain to the HSTS preload list at hstspreload.org once you are confident the configuration is stable. Note: preload is a permanent commitment — browsers will enforce HTTPS even on the very first visit, with no fallback.

Verification Steps

1. Run: curl -s -I https://yourdomain.com | grep -i strict-transport-security — confirm the max-age value is 31536000 or higher.
2. Visit https://securityheaders.com and enter your domain — the HSTS row should show a green pass with the updated max-age.
3. Check subdomains separately if includeSubDomains was added, to ensure none are HTTP-only (which would break access).

Code Examples (nginx / apache / express)

# Nginx — max-age too short
add_header Strict-Transport-Security "max-age=86400" always;

# Apache — max-age too short
Header always set Strict-Transport-Security "max-age=86400"

# Express/Node.js (using helmet) — max-age too short
app.use(helmet.hsts({ maxAge: 86400 }));

# Nginx — recommended (2 years)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# Apache — recommended (2 years)
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

# Express/Node.js (using helmet) — recommended (2 years)
app.use(helmet.hsts({
  maxAge: 63072000,          // 2 years in seconds
  includeSubDomains: true
}));

Best Practices

• Use a short max-age (e.g., 86400) only during initial HSTS rollout to test for issues, then increase to 1–2 years once confirmed stable.
• Always verify that all subdomains are HTTPS-capable before adding includeSubDomains, as it will block HTTP-only subdomains for the full max-age duration.
• Treat the preload directive as a permanent, irreversible commitment — removal from the preload list can take months to propagate to all browsers.

References

• cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
• developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security
• hstspreload.org/
• cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html