What Is a Man-in-the-Middle Attack?

Quick answer
A man-in-the-middle (MITM) attack secretly intercepts traffic between two parties, letting the attacker read or alter it.
The classic example is unencrypted Wi-Fi, where an attacker sits between you and the sites you visit.
The primary defense is TLS with proper certificate validation, which encrypts and authenticates the connection.

What is a man-in-the-middle attack?

A man-in-the-middle attack is an attack in which a third party positions itself between two communicating parties, intercepting their messages while both believe they’re talking directly to each other. The attacker can passively read the traffic or actively modify it — injecting commands, redirecting requests, or swapping content — without either side noticing.

How it works

On an unencrypted or misconfigured network, an attacker can intercept traffic between a user and a server, relaying each side’s messages while recording everything. A common variant is a rogue Wi-Fi access point in a café that poses as the legitimate network. Against encrypted traffic, the attacker may try to present a fake certificate or downgrade the connection to plaintext; proper validation defeats these tricks.

How to defend

The core defense is TLS (the “s” in HTTPS): it encrypts the traffic and, through certificate validation, proves the server is who it claims to be. Additional layers include certificate pinning for sensitive apps, security headers like HSTS to force HTTPS, and avoiding untrusted networks for sensitive work.

Where this bites vibecoders
The classic generated-code mistake is a client that talks to an API over plain HTTP, or disables TLS certificate verification “to make it work in development” and then ships that flag. The first habit to enforce: HTTPS everywhere in production, and never disable certificate validation outside a controlled test. A working insecure connection is exactly what a MITM attacker is waiting for.

Where AI coding assistants get this wrong

Hardcoding http:// endpoints instead of HTTPS.
Disabling TLS verification to silence a dev-environment warning, then leaving it in.
Ignoring certificate pinning where it matters.
Storing or transmitting secrets over unencrypted channels.

Checklist

Use HTTPS for every production connection.
Validate certificates; never disable verification in production.
Add HSTS so browsers refuse plaintext downgrades.
Avoid transmitting credentials over unencrypted links.
Treat untrusted networks as hostile for sensitive work.

FAQ

Is HTTPS enough to stop MITM?

For most cases, yes: TLS encrypts and authenticates the connection, and modern certificate validation makes interception detectable. No defense is absolute — compromised certificates or endpoint malware remain — but HTTPS is the single most important control.

What is certificate pinning?

Certificate pinning hardcodes which certificate (or authority) an app will accept for a given server, so even a maliciously issued certificate is rejected. It’s valuable for high-security apps but adds operational risk if certificates rotate incorrectly.

Is a VPN the same as TLS?

No. A VPN encrypts the path between you and a VPN server; TLS encrypts the connection between you (or your app) and the destination. They can complement each other but protect different links.