A man in the middle attack, which OWASP now calls manipulator in the middle, places an attacker between two systems so they can read, insert or change the traffic. Encryption with certificate validation stops most cases. The attacks that still work usually depend on a user clicking past a warning.
How does the attack work?
OWASP describes the mechanics for HTTP. The attacker splits the original TCP connection into two: one between the client and the attacker, another between the attacker and the server. The attacker then acts as a proxy and can read, insert and modify data. With plain HTTP, headers and payloads are in cleartext, so a session cookie can be read straight from a header.
Constructed example on a shared cafe network. A laptop joins the Wi-Fi. A second device on the same network uses ARP spoofing, a technique OWASP lists among the capabilities of LAN interception tools, to convince the laptop that the attacker's hardware address belongs to the router. Now the laptop's packets go to the attacker first. If the user is on a plain HTTP page, the cookie is visible. If the page uses HTTPS, the attacker has a harder job.
Why does HTTPS change the picture?
TLS 1.3, defined in RFC 8446, is designed to prevent eavesdropping, tampering and message forgery. The client checks the server's certificate against trusted authorities, then derives keys only the two endpoints share. An interceptor can still forward packets, but it sees ciphertext.
OWASP's page notes the same attack can run over HTTPS by establishing two independent TLS sessions, one on each side. That only succeeds when the client accepts the attacker's certificate. Two situations allow it: the user ignores a browser warning, or the attacker holds a certificate the client trusts for that name, for example from a compromised certificate authority or a trusted root that was added on the device.
What actually breaks the attack?
Think in layers.
- Encryption in transit everywhere, including internal service calls. Plain HTTP leaves nothing to defend.
- Strict certificate validation in your own code. Disabling verification to make a test pass is the classic way a mobile app or script becomes interceptable.
- HSTS, which OWASP lists as a control, tells browsers to use HTTPS only for your domain, so a downgrade to HTTP fails.
- Secure session handling, such as cookies marked Secure, limits what a stolen header can do.
- Network hygiene on the access side: avoid unknown Wi-Fi for sensitive work, or use a trusted VPN, and treat certificate warnings as stop signs.
How to check or apply this
- Search your code for settings that turn off certificate or hostname verification. Remove them from anything that ships.
- Confirm every public endpoint redirects to HTTPS and sends an HSTS header.
- Mark session cookies Secure and HttpOnly.
- Check internal traffic between services. If it is plain, plan to encrypt it, starting with anything carrying credentials.
- Train staff on what a certificate warning means and who to call.
- Keep a list of root certificates deployed on managed devices, and review additions.
What about attackers who are not on the network?
Interception can also happen at other points such as a compromised router, a rogue access point or a misissued certificate. The defenses above still apply, because they protect the connection regardless of the path.
How would you notice an attack in progress?
Often you would not, which is why prevention matters more than detection. Signs include certificate warnings on sites that were fine yesterday, a gateway address that suddenly maps to an unfamiliar hardware address on your local network, and sessions that drop and reappear. On a managed network, switch features that watch address resolution traffic can flag spoofing. For your own services, monitor for unusual certificate changes and for clients that start failing validation, which may point to interception somewhere on the path.
Quick check
Does a padlock mean I cannot be intercepted?
No. It means the connection is encrypted to whoever presented a certificate your device trusts. If you accepted a warning or a trusted root was added, an interceptor can still sit in the middle.
Is a VPN enough to stop man in the middle attacks?
It protects the path between you and the VPN endpoint. Beyond that point you still depend on HTTPS and certificate checks.
Sources
Last reviewed: 18 October 2026.
