Your Website Accepts Unencrypted Connections — Here's What to Fix

Vulnerability Explanation

The server listens on port 80 (HTTP) and serves content or returns no redirect response, meaning clients that initiate an HTTP connection are never upgraded to TLS. Any data exchanged over this initial connection — including session cookies, form data, and authentication tokens — is transmitted in plaintext. An attacker on the same network segment can passively sniff this traffic or actively intercept and manipulate it (MITM). Tools such as sslstrip can silently strip HTTPS redirects and keep the victim on HTTP for the entire session, even when the server would otherwise redirect.

Root Cause

The web server or application is not configured with a virtual host or middleware rule that issues a permanent redirect (HTTP 301) from port 80 to the HTTPS equivalent. HTTPS may be fully functional on port 443, but without an explicit redirect rule on port 80, clients that arrive via HTTP are never promoted to the secure channel.

Technical Impact

An attacker positioned on the network path (e.g. a rogue Wi-Fi access point, a compromised router, or an ISP-level intercept) can read or modify all HTTP traffic. Practical outcomes include session cookie theft leading to account takeover, credential harvesting from login forms submitted over HTTP, and content injection (e.g. malicious scripts injected into HTTP responses). The risk is highest for users on shared or public networks.

Severity Justification

Exploitation requires network-level access (same network segment or ISP-level position), which is a realistic but not trivially achieved condition. The impact when exploited can be significant (session hijacking, credential theft), but the attacker prerequisite prevents this from being rated high. CVSS estimate: 5.9 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N).

Affected Components

• HTTP listener on port 80 — all versions

Remediation Steps

1. Add a permanent 301 redirect rule on your port-80 server block or virtual host to redirect all traffic to the HTTPS equivalent URL (see config examples below). Use 301, not 302 — browsers cache 301 redirects, reducing future HTTP exposure.
2. Add an HSTS response header on your HTTPS (port 443) server. Start with a short max-age (e.g. 86400 seconds / 1 day) to test, then increase to 31536000 (1 year) once confirmed working. Optionally add includeSubDomains if all subdomains also support HTTPS.
3. If the site is behind a CDN or reverse proxy (Cloudflare, AWS CloudFront, etc.), configure the redirect at the CDN layer and ensure the origin does not create a redirect loop. For Cloudflare, enable 'Always Use HTTPS' and set SSL mode to 'Full (strict)'.
4. Verify no redirect loops exist by running: curl -IL http://yourdomain.com and confirming a single 301 → 200 chain with no intermediate HTTP hops.
5. Once HSTS has been stable for several months, consider submitting the domain to the HSTS preload list (hstspreload.org) to eliminate the first-visit HTTP window entirely.

Verification Steps

1. Run: curl -IL http://yourdomain.com — confirm the first response is HTTP/1.1 301 with a Location header pointing to https://.
2. Check the HTTPS response includes the Strict-Transport-Security header: curl -sI https://yourdomain.com | grep -i strict-transport
3. Test with SSL Labs (https://www.ssllabs.com/ssltest/) — the report will flag missing HSTS and redirect issues.
4. Open the site in a browser using http:// and confirm the address bar switches to https:// with no 'Not Secure' warning.

Best Practices

• Always issue 301 (permanent) redirects, not 302 (temporary) — browsers cache 301s, reducing future unencrypted requests.
• Pair the HTTP redirect with an HSTS header on the HTTPS response so browsers learn to skip HTTP entirely on subsequent visits.
• Ensure session cookies are marked with the Secure flag so they are never transmitted over HTTP even if a redirect is missed.
• If running an API, consider rejecting HTTP requests outright (returning 400 or 403) rather than silently redirecting — API clients often follow redirects without warning, which can expose secrets.

References

• owasp.org/Top10/A02_2021-Cryptographic_Failures/
• developer.mozilla.org/en-US/docs/Web/Security/Attacks/MITM
• https.cio.gov/hsts/
• blog.nginx.org/blog/http-strict-transport-security-hsts-and-nginx