Why Missing HTTPS Creates Dangerous Plaintext Transmission Vulnerabilities

Basic Concepts

HTTP transmits data in clear text; HTTPS = HTTP + TLS encryption channel, encrypting payload before transmission so intercepted traffic appears as ciphertext.

Missing HTTPS means URLs still use http://, creating a plaintext transmission vulnerability.

Attack Principle

On a public Wi‑Fi network, a man‑in‑the‑middle can capture all HTTP requests, exposing usernames, passwords, phone numbers, ID numbers, and order details. HTTPS prevents reading the data but does not stop capture.

Real‑World Scenarios

Login interface (high risk) – Endpoint http://xxx.com/login with parameters username=ZhangSan&password=123456. An attacker can read credentials directly.

Mobile app / mini‑program backend – All APIs use HTTP. Example request http://api.xxx.com/pay?phone=138XXXX&card=bankcardnumber leaks phone number and bank card.

Internal management system – Intranet assumes external users cannot reach it and omits HTTPS. Employees using office Wi‑Fi have admin credentials captured by internal sniffers.

Open third‑party API integration – External service calls an API over HTTP, transmitting signature keys and sensitive business data, which can be eavesdropped or tampered.

Mixed‑content situations arise when a page is served over HTTPS but resources such as upload endpoints, images, or internal APIs remain HTTP, preserving plaintext risk.

Harms of Plaintext Transmission

Information eavesdropping – theft of accounts, phone numbers, IDs, addresses, financial data.

Data tampering – a MITM can modify parameters, e.g., changing a payment amount from 100 CNY to 1 CNY.

Phishing hijack – ISPs or malicious networks can inject ads or redirect users to fraudulent pages.

Facilitates replay attacks – captured full requests can be replayed; additional replay‑prevention is required even with HTTPS.

Standardized Countermeasures (from easy to hard)

Deploy site‑wide HTTPS

Obtain an SSL/TLS certificate (free Let’s Encrypt for public services, commercial certificates for enterprise).

Configure the certificate in Nginx or Apache and open port 443.

Disable legacy protocols (SSLv3, TLS 1.0, TLS 1.1); keep only TLS 1.2 and TLS 1.3.

Force HTTP‑to‑HTTPS redirection – automatically redirect any http://domain request to https://domain to prevent manual bypass.

Enable HSTS header – instruct browsers to always use HTTPS for the domain, mitigating downgrade attacks.

Application‑layer encryption for highly sensitive fields – encrypt data such as bank cards or passwords with AES before transmission, protecting against misconfigured certificates or internal debugging.

Eliminate mixed‑content resources – ensure pages served over HTTPS do not load JavaScript, images, or API calls over HTTP.

Common Pitfalls

Assuming internal LAN or corporate network does not need HTTPS; internal packet capture is still possible.

Believing native mobile apps cannot be sniffed; tools like Charles or Fiddler can capture HTTP traffic from Android and iOS apps.

Thinking HTTPS removes the need for API signatures or permission checks; transport encryption does not prevent authorization or replay attacks.

Assuming HTTPS traffic cannot be captured; installing a trusted root certificate on a device allows decryption for debugging.

One‑Sentence Takeaway

Plaintext HTTP exposes data to eavesdropping and tampering; the remedy is full‑site HTTPS deployment, forced redirects, HSTS hardening, and optional application‑layer encryption for the most sensitive payloads.