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

A man-in-the-middle attack is when an attacker secretly positions themselves between two parties, relaying and potentially altering their messages while each side believes it is communicating directly and privately with the other.

What is ARP spoofing?

ARP spoofing is a local-network MITM technique where an attacker sends forged ARP messages to associate their device with another host's IP address, causing traffic meant for that host to flow through the attacker instead.

Is public Wi-Fi safe from man-in-the-middle attacks?

Public Wi-Fi is a classic MITM environment, but properly implemented TLS protects your data even on a hostile network. The risk comes from sites without TLS, ignored certificate warnings, or evil-twin access points combined with weak app security.

What is certificate pinning?

Certificate pinning hardcodes which certificate or public key a client will accept for a specific server, so even a fraudulently issued but technically valid certificate is rejected. It is common in mobile apps to resist sophisticated interception.

Glossary · Security

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

A man-in-the-middle attack is an interception: the attacker quietly inserts themselves between two parties — say, your browser and your bank — relaying messages back and forth so each side believes it is talking directly and privately to the other. From that position, the attacker can read everything, and often alter it: steal credentials, hijack a session, or silently change a payment destination mid-transfer.

The core idea

Every secure conversation rests on two guarantees: that nobody else can read it (confidentiality) and that you are actually talking to who you think you are (authentication). A man-in-the-middle attack breaks the second to defeat the first. If the attacker can convince your browser that they are the bank and convince the bank that they are you, then encryption alone does not help — you have simply established a perfectly secure channel with the wrong party. This is why authentication, not just encryption, is the heart of the defense.

How attackers get in the middle

There are many roads to the middle position. On a local network, ARP spoofing lets an attacker masquerade as the gateway so all traffic flows through them. Rogue or "evil twin" Wi-Fi access points lure devices onto a network the attacker controls. DNS spoofing and cache poisoning redirect a name to the attacker's server. Compromised routers, malicious proxies, and BGP hijacks operate at larger scale. The common thread is that the attacker gains a position on the path and then impersonates one or both endpoints — the technique varies, but the goal is always to be the invisible relay.

Why TLS is the answer

The primary defense is TLS, and specifically the authentication half of it. TLS encrypts the channel, but its anti-MITM power comes from certificates: the client checks the server's certificate against trusted authorities in the public key infrastructure, so an interceptor cannot pretend to be your bank without a valid certificate your browser will accept — which they cannot obtain. This is why the certificate warning your browser throws is not noise; clicking through it is often the exact moment a man-in-the-middle attack succeeds, because you have manually overridden the one check that stops it.

Hardening beyond basic TLS

Strong systems add layers. HTTP Strict Transport Security (HSTS) forces browsers to use HTTPS and refuse to downgrade, defeating attacks that try to strip encryption away. Certificate pinning hardcodes which certificate a client will trust for a given server, so even a fraudulently issued certificate is rejected — common in mobile apps. Mutual TLS authenticates both sides, not just the server, which matters for service-to-service traffic in a zero trust architecture. And robust session handling limits the damage if an attacker does manage to capture a token.

At QUANT LAB

We defend against interception by getting the transport layer right and proving it holds. The web applications and APIs we build enforce TLS everywhere, set HSTS, and validate certificates rather than trusting whatever shows up. During a penetration test, intercepting traffic is one of the first things we attempt — and we routinely find apps that accept invalid certificates, mobile clients with no pinning, or mixed HTTP and HTTPS content that opens a downgrade path. Each of those quietly hands an attacker the middle seat, and each is fixable before it is exploited.

Staying off the middle seat

The defensive checklist is well established. Use TLS for everything, with no plaintext fallbacks, and never ship code that disables certificate validation "to make it work." Enable HSTS and consider pinning for high-value clients. Treat certificate warnings as hard stops, both in apps and in user training. On sensitive networks, watch for ARP and DNS anomalies. And design on the assumption that the network is hostile — which is exactly the zero-trust posture — so that even an attacker who reaches the middle finds an authenticated, encrypted channel they cannot usefully break.

Long-form deep-dives that use this term

All posts

Related terms

Worried about traffic interception?

We build apps that enforce TLS correctly and test them by trying to intercept the traffic ourselves. Book a 30-minute call.

Penetration testing