Missing Security Header Leaves Connections Vulnerable to Interception

Vulnerability Explanation

The server does not return a Strict-Transport-Security (HSTS) response header on HTTPS responses. HSTS instructs browsers to automatically upgrade all future connections to HTTPS and refuse to connect over plain HTTP for the declared max-age period. Without it, browsers have no persistent memory of the site's HTTPS requirement. A user who navigates to the site via an HTTP link or types the domain without a scheme will send an unencrypted initial request. A network-positioned attacker can intercept this first request and perform an SSL-stripping attack — transparently downgrading the connection to HTTP and proxying traffic without the user's knowledge. Crucially, no browser warning is shown during a successful SSL-strip, making the attack invisible to the victim.

Root Cause

The web server or application framework is not configured to emit the Strict-Transport-Security response header on HTTPS responses. This is a configuration omission, not a code defect. HSTS is an opt-in mechanism (RFC 6797) and must be explicitly enabled by the server operator.

Technical Impact

A network-positioned attacker (e.g., on the same LAN or a rogue Wi-Fi access point) can perform an SSL-stripping man-in-the-middle attack against users whose first request goes over HTTP. This allows interception of session cookies, credentials, and sensitive form data. Additionally, without HSTS, browsers will allow users to click through invalid certificate warnings, weakening the overall TLS security posture.

Severity Justification

Exploitation requires a network-adjacent attacker and user interaction (the victim must initiate an HTTP connection). There is no direct server-side exploit. CVSS scores from authoritative scanners range from 5.8 to 6.5 (CVSS 3.x), reflecting the realistic but conditional nature of the attack. Rated 'high' by the scanner due to the sensitivity of data that could be exposed if exploited.

Affected Components

• Web server HTTPS response headers — all versions without HSTS configured

Remediation Steps

1. Add the HSTS header to your HTTPS server block only (never on HTTP responses). Start with a short max-age (e.g., 300 seconds) to test, then increase to 31536000 (1 year) once confirmed working. See code examples below for Nginx, Apache, and Node/Express.
2. Ensure your site has a valid TLS certificate and that all subdomains you intend to cover with includeSubDomains also have valid certificates — HSTS will block access to any subdomain without a trusted cert.
3. Deploy and verify the header is present on all HTTPS responses using: curl -sI https://yourdomain.com | grep -i strict-transport
4. Gradually increase max-age: start at 300 (5 min), then 86400 (1 day), then 2592000 (30 days), then 31536000 (1 year) over successive deployments.
5. Optionally, submit your domain to the HSTS preload list at https://hstspreload.org once max-age is at least 31536000 and includeSubDomains is set — this protects users even on their very first visit.

Verification Steps

1. Run: curl -sI https://yourdomain.com | grep -i strict-transport-security — the header should appear with your configured max-age.
2. Visit https://securityheaders.com and enter your domain — confirm the HSTS row shows green.
3. Check the browser DevTools Network tab on an HTTPS response and confirm the Strict-Transport-Security header is present.
4. Test that HTTP requests redirect to HTTPS: curl -sI http://yourdomain.com — you should receive a 301 redirect to the HTTPS URL.

Code Examples (nginx / apache / javascript)

# No Strict-Transport-Security header present in server response

# Nginx — inside the HTTPS server{} block:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Apache — inside the HTTPS <VirtualHost *:443> block:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Node.js / Express — using Helmet middleware:
const helmet = require('helmet');
app.use(helmet.hsts({
  maxAge: 31536000,
  includeSubDomains: true
}));

Best Practices

• Always set HSTS only on HTTPS responses — browsers ignore the header if received over HTTP, and it cannot be used to bootstrap a secure connection from scratch.
• Use includeSubDomains only after confirming all subdomains (including staging/dev) have valid TLS certificates — HSTS will block access to any subdomain that fails certificate validation.
• Ramp up max-age gradually in production to avoid locking users out if you need to roll back to HTTP for any reason.
• Consider HSTS preloading (hstspreload.org) for maximum protection, but treat it as a one-way, permanent commitment — removal from the preload list can take months to propagate.

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
• datatracker.ietf.org/doc/html/rfc6797
• hstspreload.org/