Missing HTTP Redirect — 12% of Login Credentials Exposed
12% of login requests over HTTP due to missing redirect — session hijacking spikes.
- HTTP is plaintext on port 80. Anyone on the path — coffee shop WiFi, ISP, corporate proxy, or nation-state — can read your users' passwords, tokens, and credit cards in cleartext.
- HTTPS is HTTP inside TLS. It gives you encryption, server authentication, and integrity checks in one package.
- The TLS handshake uses asymmetric crypto (public/private keys, usually ECDHE) to safely negotiate a session key, then flips to fast symmetric encryption — AES-GCM or ChaCha20 in practice.
- Port 443 is default for HTTPS. Modern browsers shame HTTP pages with big "Not Secure" warnings, Google continues to downgrade them in search, and features like Service Workers, geolocation, camera access, and Private Access Tokens simply refuse to work on insecure contexts.
- HTTP/2 and especially HTTP/3 (over QUIC) are HTTPS-only in practice. If you're not on TLS, you're stuck with 20-year-old performance characteristics and head-of-line blocking.
- The biggest production foot-gun: the padlock only means the pipe is encrypted and the certificate validated for that domain. It says nothing about whether the site is legitimate, the backend is secure, or the code isn't leaking data.
Picture sliding a note across the table in a busy café. With HTTP, it's written in plain ink — the waiter, the person at the next table, or anyone who snatches it mid-air can read your PIN, your secrets, everything. HTTPS is the same note, but now it's in a locked briefcase that only you and your friend have the key for. The briefcase still travels the same route through the café. The path hasn't changed. But the contents are now private, can't be altered without detection, and you have high confidence it's actually going to your friend, not an impostor pretending to be them. That's the entire game.
Every single time a user opens your site or calls your API, their browser and your server are having a very specific conversation using HTTP or HTTPS. Get this wrong and passwords leak, sessions get hijacked, Google buries you in search, and half your fancy new browser features stop working.
HTTP dates back to 1991. Tim Berners-Lee designed it for simplicity and speed when the web was mostly academic pages. Privacy wasn't even on the radar. Everything travels in plain text. Passwords, session cookies, API keys, credit card details — all completely readable by anyone with a packet sniffer on the same network path.
HTTPS is simply HTTP sent over TLS. The TLS layer adds the three things the original protocol never had: confidentiality through encryption, authentication through certificates, and integrity so tampering is detectable.
By April 2026 this isn't optional theater. Chrome, Firefox, and Safari actively mark HTTP pages as 'Not Secure' with increasingly aggressive UI. Google has been using HTTPS as a ranking signal for years and only gets stricter. Features like geolocation, camera access, service workers, and the newer Private Access Tokens flat-out refuse to work on insecure origins. The real failures I've seen in production aren't usually dramatic MITM attacks — they're the subtle ones: certificates expiring at 3am on a Friday, mixed content quietly breaking payment flows after a frontend change, missing HSTS headers allowing downgrade attacks on public networks, or developers testing exclusively on plain HTTP localhost and getting surprised when prod behaves differently.
Most teams treat HTTPS as a checkbox. The engineers who ship reliably are the ones who understand the handshake, certificate validation chains, Certificate Transparency logs, and the exact guarantees (and limitations) TLS actually provides.
What HTTP Is and How a Browser Actually Fetches a Page
HTTP stands for HyperText Transfer Protocol — the agreed-upon set of rules browsers and web servers follow when talking to each other. When you type a URL and hit Enter, the browser does a DNS lookup, opens a TCP connection on port 80, sends a structured text request, and receives a structured text response containing HTML (and eventually CSS, JS, images, etc.).
A typical modern page still triggers dozens of these request-response cycles. Every asset is its own conversation. The critical reality in 2026 is that all of this is still plain text when using HTTP. Anyone on the network path can read it with trivial tools. This is why HTTP-only sites belong only in controlled internal environments or local development.
- DNS resolves the domain to an IP address — the phone book of the internet
- TCP connection on port 80 is the 'phone line' between browser and server
- The request is structured text: request line, headers, blank line, optional body
- The response is also structured text: status line, headers, blank line, body (HTML/CSS/JS)
- Every asset (image, script, CSS, font) triggers its own request-response cycle
Why HTTP Alone Is Dangerous — The Man in the Middle
A Man-in-the-Middle (MITM) attack happens when an attacker inserts themselves between you and the server and can read or modify everything. On plain HTTP this is trivial. Tools like Wireshark, tcpdump, or bettercap make it almost boring. The attacker doesn't need to break any cryptography because there is none.
HTTP has three fatal weaknesses on the public internet: no privacy (everything readable), no integrity (data can be changed silently), and no authentication (you have no proof you're talking to the real server). HTTPS, via TLS, solves all three at once.
How HTTPS Works — TLS, Certificates, and the Handshake Explained
HTTPS is not 'HTTP with encryption bolted on.' It is HTTP transported over TLS (Transport Layer Security). TLS delivers the three properties HTTP lacked: privacy (encryption), authentication (certificates), and integrity (message authentication codes).
The TLS handshake lets the client and server agree on a shared session key using asymmetric cryptography without ever sending the key itself. Once established, they switch to fast symmetric encryption for the actual HTTP traffic. The server proves its identity with a certificate signed by a trusted Certificate Authority. In 2026, that certificate is almost always from Let's Encrypt, and browsers expect TLS 1.3 with modern cipher suites.
- Client sends ClientHello with supported versions, cipher suites, and key share
- Server replies with ServerHello, its certificate chain, and its own key share
- Both sides independently compute the same session key (usually via ECDHE)
- All subsequent data — including the HTTP request — is encrypted with symmetric AES (or ChaCha20) using that key
- TLS 1.3 does this in 1 round-trip in most cases. 0-RTT is possible but has tradeoffs
HTTP Status Codes, Request Methods, and Headers You'll Use Daily
Every HTTP conversation consists of a request and a response, both with strict formatting. Methods describe intent. Status codes tell you what happened. Headers carry metadata that makes the whole system work — caching, authentication, content negotiation, security policies.
GET should be safe and idempotent. POST is the workhorse for mutations. PUT and DELETE are idempotent. PATCH is for partial updates. Knowing the difference isn't academic — it affects caching, retry logic, and whether your API is pleasant to use. Status code families (2xx success, 3xx redirection, 4xx client error, 5xx server error) are the first signal when something breaks.
Missing HTTP-to-HTTPS Redirect Exposes Login Credentials on Public Wi-Fi
- Always redirect HTTP to HTTPS at the earliest possible point — never serve real application content on both protocols simultaneously. The redirect itself should be the only thing that ever lives on port 80.
- HSTS is your memory enforcement layer. Set it with a long max-age on every response (not just the homepage), includeSubDomains, and eventually preload. I've seen teams get burned by setting it only on the root path.
- Test your setup the way real users and attackers do: curl -I http://yoursite.com should return 301 with a Location header pointing to HTTPS. If you see 200, you're still exposed.
- HSTS preload protects first-time visitors and removes the initial HTTP window entirely. Submit to the preload list once you're confident in your redirect strategy — it is not easily reversible.
Key takeaways
Common mistakes to avoid
4 patternsUsing HTTP for localhost and assuming production HTTPS will behave the same
Thinking the padlock means the website is safe or trustworthy
Not redirecting HTTP to HTTPS — leaving both protocols active
Serving mixed content — loading some resources over HTTP on an HTTPS page
Interview Questions on This Topic
Can you walk me through exactly what happens when a user types 'https://google.com' in their browser and presses Enter — from DNS lookup through to the page rendering?
Frequently Asked Questions
That's Computer Networks. Mark it forged?
3 min read · try the examples if you haven't