What Is a Man-in-the-Middle Attack and How Do You Stop One?

A man-in-the-middle (MITM) attack is when someone secretly positions themselves between two parties who think they are communicating directly — a browser and a website, a laptop and a Wi-Fi router, or two people messaging each other — so they can intercept, read, or alter the traffic passing between them. The attacker relays messages back and forth so convincingly that neither side realizes a third party is listening in. The best defenses are ones you can check yourself: confirm a site is using HTTPS, never dismiss a browser certificate warning, and avoid logging into sensitive accounts on open or unfamiliar Wi-Fi networks.

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

A man-in-the-middle attack is a form of eavesdropping and interception in which an attacker inserts themselves into a conversation or data exchange between two parties, each of whom believes they are communicating directly with the other. The U.S. National Institute of Standards and Technology (NIST) describes it in its computer security glossary as an attack in which an adversary positions themselves between a user and a system (or between two communicating systems) in order to intercept and, potentially, alter the data traveling between them.

The term is sometimes written as "person-in-the-middle" or "on-path attack," and OWASP's community documentation now favors "manipulator-in-the-middle" to make clear that the attacker isn't just listening — they can actively insert, modify, or drop data as it passes through. Wikipedia's overview of the attack frames it the same way: an intruder sits between two parties and covertly relays, and possibly alters, the communications each side believes is private and direct.

Unlike attacks that compromise a single device through malware, a MITM attack exploits the path the data travels — a shared Wi-Fi network, a local network segment, a DNS lookup, or a TLS handshake — rather than the endpoints themselves. That is why defenses tend to focus on securing the channel (encryption, certificate validation) and the network path (trusted Wi-Fi, patched routers), not just the device.

How a Man-in-the-Middle Attack Works

Every MITM attack follows the same basic structure, regardless of the specific technique used to pull it off:

1. Interception. The attacker gets access to the communication path — by joining the same Wi-Fi network, poisoning a local network's address tables, spoofing a DNS response, or compromising a router — so that traffic from the victim flows through the attacker instead of going directly to its destination.
2. Impersonation. The attacker presents themselves to each side as the other party. To the user's device, the attacker looks like the legitimate website or Wi-Fi access point; to the real website or server, the attacker looks like the legitimate user.
3. Decryption or downgrade (if needed). If the connection is encrypted, the attacker must either present a fraudulent certificate the victim's device accepts, exploit a weak or misconfigured TLS setup, or strip the connection down to unencrypted HTTP so the traffic is readable.
4. Observation or manipulation. Once inside the data path, the attacker can passively read sensitive information such as login credentials, session cookies, and payment details, or actively alter the data — for example, changing the destination account number in a transaction, as OWASP's documentation notes is possible once a connection is split into two attacker-controlled sessions.

This structure explains why strong, properly validated encryption is such an effective countermeasure: even if an attacker successfully intercepts the traffic, they still need a way to either defeat the encryption or trick the victim's device into trusting a fraudulent identity.

Common MITM Attack Vectors

MITM attacks aren't a single technique — they're a category of attacks that share the same goal (sitting between two parties) but use very different methods to get there. The table below summarizes the most common vectors, the warning signs associated with each, and the main way to prevent it.

How HTTPS and TLS Defend Against MITM Attacks

Transport Layer Security (TLS) — the protocol behind the "https://" in a web address — is the primary technical defense against man-in-the-middle attacks on the internet. TLS does two things that directly counter the structure of a MITM attack described above: it encrypts the data in transit, so intercepted traffic is unreadable without the correct keys, and it authenticates the server (and optionally the client) using a digital certificate issued by a trusted certificate authority.

According to OWASP's documentation on manipulator-in-the-middle attacks, even over HTTPS an attacker can attempt to run two separate TLS sessions — one with the victim and one with the real server — but this only works if the victim's device can be convinced to accept a fraudulent or mismatched certificate. Modern browsers are built to refuse that: if a certificate is self-signed, expired, revoked, or issued for the wrong domain, the browser shows a hard warning before the page loads. That warning is the browser telling you that certificate validation — the core defense against MITM on the web — has failed.

A few additional controls strengthen this baseline defense:

• HTTP Strict Transport Security (HSTS). A site can send a header instructing browsers to only ever connect to it over HTTPS, which closes the window SSL-stripping attacks rely on (the moment a browser is willing to try plain HTTP first).
• Certificate Transparency. Public, auditable logs of issued certificates make it harder for a fraudulent certificate authority to issue a convincing fake certificate without being noticed — Wikipedia's entry on the attack notes this has largely replaced the older, now-deprecated HTTP Public Key Pinning approach.
• DNSSEC. Cryptographically signing DNS records helps prevent the DNS-spoofing vector from silently redirecting users to a malicious server in the first place.

None of these controls require any action from an everyday user beyond one simple habit: never click through a certificate warning, and never proceed on a site that should be secure but isn't showing a lock icon or "https://" prefix.

Warning Signs You Might Be a Target

MITM attacks are designed to be invisible, so there's rarely a single, unmistakable sign. That said, a few things are worth treating as red flags:

• Certificate warnings. Any browser warning about an invalid, expired, self-signed, or mismatched certificate on a site you've visited safely before.
• Unexpected HTTP instead of HTTPS. A site that normally shows a lock icon suddenly loading without one, or the address bar showing "http://" where you'd expect "https://".
• Duplicate Wi-Fi network names. Seeing two networks with the same or very similar name in a public venue, especially if one is open and one requires a password.
• Unusual login prompts. Being asked to log in again unexpectedly, or a login page that looks slightly different from usual.
• Unexplained connection slowdowns. Not conclusive on its own, but added latency can be a byproduct of traffic being relayed through an attacker's system.

None of these guarantee an attack is underway, but each one is a legitimate reason to stop, disconnect, and re-verify the connection before entering credentials or payment information.

How to Protect Yourself From MITM Attacks

Most effective MITM defenses are habits rather than tools, though a couple of tools make those habits easier to maintain consistently.

• Use a VPN on public or untrusted Wi-Fi. A reputable VPN encrypts your traffic between your device and the VPN provider, which blocks most local-network interception techniques like ARP spoofing and rogue hotspots from reading or altering your data, even on a compromised network.
• Browse HTTPS-only. Use a browser setting or extension that refuses plain HTTP connections, and treat any site that doesn't offer HTTPS as untrustworthy for anything sensitive.
• Never dismiss a certificate warning. Treat every certificate error as a stop sign, not a suggestion — this is the single most direct signal that TLS-based authentication has failed.
• Verify Wi-Fi networks before connecting. Confirm the exact network name and any login steps with venue staff, avoid open networks with no password, and disable auto-connect to open Wi-Fi in your device settings.
• Keep routers and firmware patched. Change default administrator credentials, disable remote administration, and apply firmware updates promptly — CISA's wireless network guidance lists this among its core recommendations.
• Audit browser extensions. Remove extensions you no longer use, and avoid granting broad "read and change all data" permissions to anything that doesn't need them.
• Use strong authentication that resists credential theft. Where available, passkeys are cryptographically tied to the legitimate site's domain, so even if an attacker intercepts a login attempt, a credential created for the real site cannot be replayed against a fraudulent one.

MITM Attacks on Public Wi-Fi: A Special Case

Public Wi-Fi deserves its own callout because it combines several MITM vectors in one setting. CISA's guidance on securing wireless networks describes evil twin attacks directly: an adversary sets up an access point that mimics a legitimate public network, often with a stronger signal, so that nearby devices connect to the attacker instead of the real network. Once connected, any unencrypted traffic can be captured outright, and encrypted traffic becomes a target for certificate-based MITM attempts or SSL stripping.

CISA's recommendations for using Wi-Fi networks safely include verifying the exact network name and password with venue staff, preferring networks secured with WPA2 or WPA3 over open networks, and disabling file sharing while connected to any public network. These are deliberately simple steps: the goal on public Wi-Fi isn't to make the network itself trustworthy, but to avoid relying on its trustworthiness at all — which is exactly what a VPN and HTTPS-only browsing accomplish.

This overlaps closely with broader network-trust models. Organizations increasingly apply the same "don't trust the network" logic at scale through zero trust security architectures, which assume every connection could be hostile and verify identity and device health on every request rather than trusting anything by default simply because it's "inside" a network perimeter.

What's Next

Man-in-the-middle techniques will keep adapting as more traffic moves to encrypted-by-default protocols: attackers increasingly target the edges of that encryption — fraudulent certificates, DNS, and local network trust — rather than trying to break TLS itself. For most people, the practical defense doesn't change much: keep HTTPS enforcement on, never override a certificate warning, patch routers and firmware promptly, and treat any public or unfamiliar Wi-Fi network as untrusted by default, using a VPN when you need to use one. As passwordless authentication methods expand and more sites adopt strict HTTPS policies like HSTS by default, the window for classic MITM techniques such as SSL stripping continues to narrow — but rogue Wi-Fi hotspots and compromised routers remain effective precisely because they target human trust and unpatched hardware rather than the cryptography itself.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage