Man-in-the-Middle Attack
A man-in-the-middle attack occurs when an attacker secretly intercepts and potentially alters communications between two parties who believe they are communicating directly with each other.
Understanding Man-in-the-Middle Attack
In a MITM attack, the attacker positions themselves between the client and server, intercepting traffic in both directions. The attacker can passively eavesdrop on the communication or actively modify messages before forwarding them. Both parties are unaware of the interception because the attacker maintains separate connections with each side.
Common MITM techniques include ARP spoofing (redirecting local network traffic through the attacker's machine), DNS spoofing (resolving domain names to attacker-controlled IP addresses), rogue WiFi access points (creating fake networks that victims connect to), SSL stripping (downgrading HTTPS connections to HTTP), and BGP hijacking (redirecting internet traffic at the routing level).
TLS (HTTPS) is the primary defense against MITM attacks. When properly implemented, TLS provides encryption (preventing eavesdropping), authentication (verifying the server's identity through certificates), and integrity (detecting any message modification). However, TLS is only effective if it is consistently enforced and certificate validation is not bypassed.
Defense-in-depth against MITM includes enforcing HTTPS everywhere with HSTS, using certificate pinning for high-security applications, implementing certificate transparency monitoring, avoiding public WiFi for sensitive operations, and ensuring applications verify TLS certificates properly rather than disabling certificate validation for convenience.
Why This Matters for Vibe-Coded Apps
Vibe-coded applications are vulnerable to MITM primarily through missing HTTPS enforcement. While most hosting platforms provide HTTPS by default, applications may still make HTTP requests to APIs, load resources over HTTP, or fail to redirect HTTP to HTTPS. Without HSTS, the first request to your domain may be over HTTP, creating a brief MITM window.
Ensure your vibe-coded app enforces HTTPS everywhere: add HSTS headers, verify all API calls use HTTPS URLs, and check that your hosting platform redirects HTTP to HTTPS. If your app communicates with third-party APIs, verify those connections use HTTPS and properly validate certificates.
Real-World Examples
DigiNotar Certificate Authority Compromise (2011)
Attackers compromised the DigiNotar certificate authority and issued fraudulent SSL certificates for Google, Yahoo, and other major domains. These fake certificates enabled MITM attacks against Iranian users, allowing the government to intercept Gmail communications. The breach led to DigiNotar's complete collapse.
Superfish Adware on Lenovo Laptops (2015)
Lenovo shipped laptops with Superfish adware that installed a self-signed root certificate and performed MITM on all HTTPS traffic to inject advertisements. This broke TLS security for every HTTPS website, allowing anyone with the (shared) Superfish private key to intercept encrypted traffic.
Wi-Fi KRACK Attack (2017)
The KRACK (Key Reinstallation Attack) vulnerability in the WPA2 WiFi protocol allowed attackers to decrypt WiFi traffic without knowing the network password. The attack worked against virtually every WiFi-connected device, demonstrating that even encrypted wireless connections can be vulnerable to MITM.
Frequently Asked Questions
Does HTTPS prevent all MITM attacks?
HTTPS prevents most MITM attacks by encrypting communication and authenticating the server. However, HTTPS can be undermined by compromised certificate authorities (issuing fraudulent certificates), installed root certificates (corporate proxies, malware), SSL stripping before HSTS is established, application code that disables certificate validation, and vulnerabilities in TLS implementations. HTTPS is the essential foundation, but defense-in-depth adds additional layers.
Can MITM attacks happen on HTTPS sites?
In limited scenarios, yes. Corporate environments often install root certificates on employee devices to inspect HTTPS traffic through proxy servers. Malware can install rogue certificates for the same purpose. Compromised certificate authorities can issue valid certificates for any domain. And the very first request to an HTTPS site (before HSTS is established) can be intercepted. HSTS preloading and certificate pinning mitigate these edge cases.
Is public WiFi safe with HTTPS?
HTTPS provides strong protection on public WiFi by encrypting your traffic. However, DNS queries may still be visible (unless using DoH/DoT), and the initial HTTPS connection can be vulnerable to SSL stripping if HSTS is not established. For general browsing on HTTPS sites with HSTS, public WiFi is reasonably safe. For high-security activities (banking, accessing sensitive data), a VPN provides an additional encryption layer.
What is SSL stripping?
SSL stripping is a MITM technique where the attacker intercepts the initial HTTP request and maintains an HTTP connection to the user while establishing an HTTPS connection to the server. The user sees HTTP (no padlock) but the attacker proxies everything through HTTPS to the real server. HSTS prevents this by telling browsers to only use HTTPS, but it requires the user to have visited the site at least once over HTTPS (unless the domain is in the HSTS preload list).
Is Your App Protected?
VAS automatically scans for vulnerabilities related to man-in-the-middle attack and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan