Man-in-the-Middle (MITM) Attack Explained Simply

A man-in-the-middle (MITM) attack is when someone secretly sits between two parties — you and a website, your app and its API — relaying messages while reading or altering them. Each side thinks it's talking directly to the other.

Where it happens

Public Wi-Fi — a café network an attacker controls, or a fake hotspot named "Airport_Free_WiFi".
Compromised routers — at home or in an office.
DNS tricks — sending you to the attacker's server when you type a real name.
Malicious proxies or software installed on a device.
On the network path — anyone who can see traffic between you and the server.

What an attacker can do

If the connection isn't encrypted (plain http://):

read everything — passwords, cookies, messages, form data
steal session cookies and log in as you
change pages — inject ads, malware or a fake login form
change downloads

How HTTPS stops it

HTTPS (HTTP over TLS) does two things that defeat MITM:

Encryption — traffic is unreadable to anyone in the middle.
Authentication — the server proves its identity with a certificate signed by a trusted certificate authority. An attacker can't produce a valid certificate for your domain, so the browser shows a big warning instead of connecting. (What is HTTPS?, The TLS 1.3 handshake)

That warning is the browser saying "someone may be in the middle". Users should never click through it on a site that normally works. (Your connection is not private)

The gap: the first HTTP request

If a user types example.com, the browser may first try http://, then get redirected to HTTPS. An attacker in the middle can intercept that first plain request and keep the user on HTTP (an "SSL stripping" attack).

HSTS closes the gap: your site tells browsers "only ever use HTTPS for me", so they skip HTTP entirely after the first visit — or from the very first visit, if you're on the HSTS preload list. (What is HSTS?)

For developers: don't undo the protection

The most common way apps become vulnerable to MITM is a developer switching off certificate checks to "fix" an error:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'   // ❌

requests.get(url, verify=False)                 # ❌

curl -k https://...                              # ❌ in scripts

These make your app accept any certificate — including an attacker's. If you see a certificate error, fix the cause: an expired certificate, a missing intermediate certificate, or a corporate proxy's CA that needs adding properly.

Other rules:

HTTPS everywhere, including APIs, webhooks and internal admin pages. (How automatic SSL works)
Secure cookies — Secure and HttpOnly flags on session cookies. (Cookies explained)
No mixed content — an HTTPS page loading scripts over HTTP can be tampered with. (Mixed content errors)
Encrypted database connections when the database is on another machine (sslmode=require or stricter). (Postgres connection strings)
Behind Cloudflare, use Full (strict) so the Cloudflare-to-server leg is encrypted and verified too. (Cloudflare 521/522/525)
For service-to-service traffic inside your infrastructure, consider mutual TLS. (Mutual TLS)

For everyone: practical habits

Check for HTTPS on any page where you log in or pay.
Never click through certificate warnings on sites you know.
Prefer mobile data or a trusted VPN on untrusted Wi-Fi.
Keep devices and browsers updated.

SSH has the same idea

When SSH warns REMOTE HOST IDENTIFICATION HAS CHANGED, it's the same protection: the server's identity doesn't match what you saw before. Investigate before accepting. (How to SSH into a server)

EasySpawn issues and renews HTTPS certificates for every app automatically, so there's no plain-HTTP gap for anyone to sit in. See how it works or join the waitlist.

What Is a Man-in-the-Middle Attack? And How HTTPS Stops It