What are MITM attacks & how to prevent them

Man-in-the-middle (MITM) attacks are one of the oldest and most persistent cybersecurity threats. Despite advancements in encryption and secure protocols, these attacks continue to exploit network and application-level vulnerabilities, putting sensitive data at risk.

This article explains how these attacks work, how they’re used in real-world scenarios, and how to protect your applications, APIs, and network traffic from being compromised.

What is a Man-in-the-Middle (MITM) attack?

A man-in-the-middle (MITM) attack is when a hacker secretly places themselves between two systems, like a user and a website, and intercepts the communication without either side knowing.

Imagine you're logging into a website. You think you're talking directly to the site, but in reality, the attacker is sitting in the middle, watching everything you send and receive. They can:

• Read your data (like passwords or messages).
• Change the content (like swapping a bank account number).
• Pretend to be one side (like impersonating the website).

This kind of attack is possible when the connection isn't fully secure, for example, if TLS (HTTPS) isn’t set up correctly, if the app doesn't check certificates properly, or if you're on an untrusted Wi-Fi network.

Why MITM attacks still persist in modern systems

Despite widespread adoption of HTTPS, TLS 1.2+, and secure-by-default frameworks, MITM attacks continue to succeed in real-world environments.

This isn’t due to a failure of cryptography, but rather to implementation gaps, overlooked assumptions, and weak trust boundaries in modern software systems.

Attackers today don’t need to “break” encryption. They exploit:

• Misconfigured TLS and certificate validation: Many applications still accept self-signed or expired certificates by default, especially in staging, internal, or mobile environments. Client libraries may silently fall back to insecure modes, skip hostname verification, or rely on outdated CA bundles. This opens the door for MITM proxies that can inject malicious certificates and proxy encrypted sessions without triggering alarms.
• Outdated or incomplete cryptographic libraries: In some stacks, especially embedded systems or legacy Java and C environments, TLS implementations lack support for modern features like forward secrecy, OCSP stapling, or strict cipher negotiation. Without these protections, encrypted sessions may be vulnerable to downgrade attacks or retroactive decryption.
• Mobile and IoT environments: Mobile apps and IoT devices often operate in high-risk network environments (e.g., public Wi-Fi, industrial networks) but fail to enforce strong transport security. Many apps disable certificate pinning during development and never re-enable it. Some IoT firmware hardcodes trust for any certificate signed by a public CA, even in production.
• Implicit trust in internal networks: Many internal services assume that being “behind the firewall” is sufficient. They accept plaintext HTTP, skip mutual TLS (mTLS), or fail to authenticate clients altogether. In reality, internal networks are not safe, compromised laptops, lateral movement, or malicious insiders can easily stage MITM attacks between microservices or internal APIs.
• User interaction exploits: Users are often the weakest link. Attackers use rogue access points, DNS spoofing, or captive portal manipulation to trick users into accepting invalid certificates or clicking through TLS warnings. Once a user approves a malicious cert, even once, future sessions may be silently intercepted.

In short, MITM attacks persist not because TLS is broken, but because our systems are often too trusting, and our defaults too permissive. Preventing MITM requires more than enabling HTTPS; it demands a mindset of explicit trust verification at every layer: transport, identity, and application.

How do MITM attacks work?

At a high level, a MITM attack has three steps:

1. Getting in the middle: The attacker finds a way to sit between the two systems (usually through Wi-Fi spoofing, ARP poisoning, or DNS tricks).
2. Intercepting or altering traffic: They capture or change the data flowing between the two parties, often without either side noticing.
3. Using that access: They might steal login info, inject malware, hijack sessions, or forward fake responses.

The effectiveness of a MITM attack depends on protocol weaknesses, poor TLS hygiene, and insecure network environments.

Common MITM attack techniques

1. ARP spoofing (network-level attack)

The attacker poisons the ARP (Address Resolution Protocol) table on a local network (e.g., office, shared Wi-Fi), making devices believe the attacker’s machine is the router. As a result, all traffic flows through the attacker.

For example, when you connect to the company Wi-Fi, an attacker running ARP spoofing can silently intercept or modify any request, even if it’s HTTPS (if they can trick your TLS).

Tools commonly used:

• arpspoof (part of dsniff)
• ettercap
• Bettercap (modern interactive CLI MITM framework)

How to defend:

• Enable Dynamic ARP Inspection (DAI) on managed switches.
• Use static ARP entries in high-security environments.
• Favor VPN tunnels when on untrusted networks.
• Assume LAN traffic may be compromised, don’t skip TLS or cert validation on internal APIs.

2. DNS spoofing (application-level attack)

The attacker tricks your app or device into resolving a legitimate domain (like login.example.com) to a malicious IP address they control.

For example, if your app fetches user profile data from https://api.myservice.com and the DNS is spoofed, it might hit an attacker’s server at 198.51.100.5, which serves fake JSON, and possibly steals tokens.

Tools commonly used

• dnsspoof (also part of dsniff)
• Bettercap (has built-in DNS spoofing modules)
• Rogue DHCP/DNS servers (built into fake AP kits)

How to defend:

• Use DNSSEC where supported (validates DNS records).
• Prefer DoH (DNS over HTTPS) or DoT (DNS over TLS) in client apps.
• In mobile/web clients, validate hostnames and certs, not just endpoints.
• Consider hardcoding IPs or verifying domain pins for high-risk operations.

3. SSL stripping (protocol downgrade attack)

The attacker downgrades an HTTPS connection to HTTP during the initial redirect. The user unknowingly submits credentials or session data unencrypted.

For example, a user types http://bank.com in a browser. Instead of being redirected to HTTPS, the attacker intercepts the initial request, responds with a fake HTTP site, and captures login data.

Tools commonly used:

• sslstrip (classic tool)
• mitmproxy (full-featured intercepting proxy)
• Bettercap (SSL stripping module)

How to defend:

• Use HSTS (HTTP Strict Transport Security):

	
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
	

• Submit your domain to the HSTS preload list so browsers never try HTTP.
• Redirect all HTTP traffic to HTTPS on the server.
• Avoid mixed content (HTTP assets on HTTPS pages).

4. Evil twin wi-fi (wireless impersonation attack)

The attacker sets up a rogue Wi-Fi network with the same SSID as a trusted one. Devices automatically connect to it, routing all traffic through the attacker’s network stack.

Tools commonly used:

• Airbase-ng (part of Aircrack-ng suite)
• Wifiphisher (social engineering and MITM)
• Bettercap in wireless AP mode
• Pineapple Nano / ESP8266 rogue AP kits

How to defend:

• Disable auto-connect to open networks.
• Use WPA3 or enterprise WPA2 with certificate-backed RADIUS if possible.
• Always use VPN in public networks, even for internal traffic.
• Educate users to look for browser warnings and certificate errors.

5. Session hijacking (token theft and impersonation)

An attacker captures authentication tokens, like session cookies or bearer JWTs, and reuses them to act as the user.

For example, your app sends an Authorization: Bearer <token> header over HTTP (or to a spoofed endpoint). The attacker steals it and uses it to call protected APIs.

Tools commonly used:

• Wireshark or tcpdump (packet sniffing)
• Burp Suite or ZAP Proxy (active interception)
• mitmproxy with cookie capture

How to defend:

• Always use HTTPS (and verify certs).
• Mark cookies as Secure, HttpOnly, and SameSite=Strict.
• Use short-lived access tokens with refresh tokens.
• Tie sessions to client fingerprinting (IP, device ID, etc.).
• Use OAuth2 with PKCE in public clients (like SPAs or mobile apps).

Impact of Man-in-the-Middle (MITM) attacks on enterprises

MITM attacks don’t just compromise individual sessions, they can introduce long-tail risks across enterprise infrastructure, especially in today’s distributed environments.

Organizations face increased exposure due to:

• Remote work and hybrid access.
• Widespread mobile device usage.
• IoT and edge deployments with weak TLS defaults.
• Frequent use of unsecured public Wi-Fi.
• Inconsistent certificate validation in internal tools.

Even a single successful MITM event can lead to:

• Theft of user credentials and access tokens.
• Installation of malware via spoofed software updates.
• Session hijacking of administrative consoles or CI/CD platforms.
• Exposure of API keys, internal service credentials, or PII.

According to the 2022 Cybersecurity Almanac (published by Cybercrime Magazine), global cybercrime caused $6 trillion in damages in 2021. That figure is expected to rise to $10 trillion annually by 2025, a large portion driven by credential theft, session hijacking, and malware injection, all common outcomes of MITM activity.

While many attacks target large enterprises, small and midsize businesses are not immune: Business News Daily reports that cyberattacks cost small businesses an average of $55,000 per incident.

Who’s most at risk?

MITM attacks often exploit the weakest link in the communication chain, making certain industries and technical environments particularly vulnerable:

• SaaS providers handling user authentication flows.
• Mobile-first apps with relaxed certificate validation or weak TLS enforcement.
• Remote teams connecting over unmanaged or open Wi-Fi.
• IoT manufacturers using outdated TLS stacks or hardcoded credentials.
• Internal dev tooling that assumes trust inside the network.

These systems often operate in untrusted environments or skip rigorous transport-layer verification, creating perfect conditions for eavesdropping, token theft, or proxy injection. If your architecture assumes network safety, it’s likely at risk.

Why this is a developer’s problem

Even though these are network-level attacks, the app side still plays a major role. Many MITM attacks succeed because:

• Apps accept invalid certificates (rejectUnauthorized: false in Node.js)
• Mobile apps disable pinning in debug builds and forget to re-enable it
• Tokens are stored or sent insecurely
• Redirects or TLS misconfigurations expose early requests to attack

How to detect a Man-in-the-Middle (MITM) attack

Because MITM attacks often reuse techniques from other threats, like phishing, spoofing, or DNS hijacking, they may seem obvious. But in practice, they’re often stealthy, subtle, and hard to distinguish from legitimate failures.

Detection requires a combination of human awareness and technical monitoring. And while spotting symptoms is useful, prevention remains the best defense.

Here are common signs that a MITM attack may be underway:

1. Unexpected disconnections or login loops

Users getting kicked out of sessions repeatedly, or needing to re-enter credentials more often than expected, can be a red flag.

Attackers rely on these “forced reauth” moments to harvest usernames and passwords. This tactic is especially common in credential replay or session hijack scenarios, where stolen tokens must be refreshed.

2. Suspicious URLs or certificate warnings

• The domain looks wrong (e.g., login-secure.account.example.net.ru)
• The certificate is self-signed or mismatched
• The browser throws warnings like “Your connection is not private”

These often indicate DNS spoofing or rogue TLS termination by a MITM device. For sensitive sites (banking, internal dashboards), users should be trained to stop and report when something feels off.

3. Unfamiliar or open Wi-Fi networks

If a device connects to “Free WiFi” or “Local Wireless” and suddenly prompts for sensitive credentials, it's a likely evil twin access point.

Even if the user isn’t actively entering data, attackers can:

• Inject JavaScript into web sessions
• Spoof captive portals
• Launch passive TLS stripping or downgrade attempts

4. Inconsistent content or web behavior

• Some images fail to load
• Scripts are blocked
• Browsers trigger mixed-content warnings
• The UI behaves inconsistently across reloads

MITM proxies may alter or degrade content when rewriting requests or injecting payloads. If these issues resolve when switching networks (e.g., from café Wi-Fi to mobile hotspot), MITM should be suspected.

5. Network logs show traffic to unknown IPs

For security teams and developers with log access, look for:

• Outbound connections to IPs outside your expected domain ranges
• TLS sessions terminating to unexpected intermediaries
• DNS lookups resolving to unusual IPs for known services

Tools like Suricata, Zeek, or EDR agents can help flag suspicious patterns.

How to prevent MITM attacks

While man-in-the-middle attacks often originate at the network layer, they succeed because of gaps in both infrastructure and application-layer defenses. Preventing them requires action from both developers and security engineers.

Below are checklists tailored to each role.

For developers: MITM prevention checklist

These are practices you should follow when writing code for client apps, web frontends, mobile SDKs, or backend services that initiate outbound connections.

Enforce HTTPS everywhere

• Use HTTPS for all requests, never fall back to HTTP, even internally.
• Redirect insecure traffic at the application level when possible.
• Avoid using protocol-relative URLs (e.g., //api.example.com).

Never disable certificate validation

• Avoid dangerous flags like:

	
rejectUnauthorized: false  // Node.js
insecureSkipVerify = true  // Go
CURLOPT_SSL_VERIFYPEER = false  // cURL/PHP
	

• These bypass the core security of TLS.
• Validate both the certificate chain and the hostname.
• Reject connections that throw TLS errors, never bypass errors in development without proper flags.
• Don’t accept self-signed certs unless strictly controlled.

Validate TLS Certificates & Endpoints

• Never disable certificate validation:

	
rejectUnauthorized: false  // Node.js (bad!)
insecureSkipVerify = true  // Go (bad!)
	

Use secure libraries and defaults

• Choose libraries that perform strict validation by default (fetch, Axios, Requests, etc.).
• Keep all TLS-dependent libraries up to date.

Implement certificate pinning (with caution)

• Especially important in mobile apps and embedded clients.
• Pin public keys or CA fingerprints to prevent rogue CAs from being accepted.
• Use libraries like:
  
  • Android: OkHttp CertificatePinner
  • iOS: NSURLSessionDelegate

Use secure cookies

• When setting session cookies, always use:

	
Set-Cookie: token=...; Secure; HttpOnly; SameSite=Strict
	

• Avoid storing tokens in localStorage unless unavoidable.
• Transmit tokens only over HTTPS.
• Use short-lived access tokens and refresh tokens.

Secure tokens in transit

• Use short-lived access tokens (e.g., 15 minutes).
• Use refresh tokens only over secure channels.
• Adopt OAuth 2.0 with PKCE for SPAs and mobile apps.

Validate redirects and hostnames

• Avoid blindly following HTTP 30x redirects without verifying destination.
• Ensure hostname verification is active for all TLS connections.

Don't assume internal networks are safe

• Use HTTPS even for local or LAN-only APIs.
• Validate TLS even on service mesh or private links.

For security engineers: Infrastructure-level defenses

These are critical configuration and operational steps to reduce MITM exposure across your environment.

Implement modern TLS configuration

• Only allow TLS 1.2 and 1.3. Disable SSL, TLS 1.0, and 1.1.
• Use secure cipher suites (e.g., ECDHE + AES-GCM).
• Validate certificate chains server-side and monitor expiration.
• Enable OCSP stapling to detect and block revoked certificates.

Deploy HTTP Strict Transport Security (HSTS)

• Force browsers to connect via HTTPS, even on the first request:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• Submit your domain to the HSTS preload list for maximum protection.

Use Mutual TLS (mTLS) where applicable

• Authenticate clients via certificates for internal APIs and critical services.
• Enforce per-service cert rotation and chain-of-trust policies.

Harden DNS infrastructure

• Use DNSSEC for public zones to prevent spoofing.
• Encourage or enforce DNS-over-HTTPS (DoH) on internal resolvers and endpoints.
• Consider internal domain allow-lists or DNS pinning for sensitive apps.

Monitor for suspicious activity

• Watch for:
  
  • Self-signed or expired certificates
  • TLS downgrade attempts
  • Unusual DNS resolution patterns
  • OCSP failures
• Deploy network intrusion detection (NIDS) or EDR tools with MITM detection capabilities.

Secure wireless & remote access

• Use WPA3 for Wi-Fi where possible; avoid open networks entirely.
• Harden VPN configurations with MFA, cert-based auth, and split tunneling controls.
• Educate employees on safe Wi-Fi practices and TLS warnings.

Apply zero trust principles

• Treat all networks—including “internal”—as untrusted.
• Require authentication, TLS, and policy checks for every connection.
• Use service identity, context-aware access, and network segmentation.

Recap: MITM is about broken trust

Man-in-the-middle attacks aren't just about cryptography, they’re about broken trust in a system. Whether it’s a mobile app skipping certificate checks, a backend service assuming internal networks are safe, or a TLS misconfiguration left unmonitored, MITM attacks exploit assumptions.

Security doesn’t start at the perimeter anymore. Every client, server, and API must actively verify who it’s talking to and protect the data in motion.

What to do next

• Audit all outbound HTTP clients for proper TLS validation.
• Enforce HTTPS with HSTS across domains you control.
• Enable OCSP stapling on your edge infrastructure.
• Rotate certificates automatically, don’t rely on calendar reminders.
• Review network logging for unencrypted or downgraded traffic.
• Enable strict redirect validation and limit token lifetime wherever possible.

Final thoughts

MITM attacks are silent failures of verification, they don’t crash your app, they intercept it. And they’re no longer limited to outdated networks or careless configurations. Today’s attackers take advantage of minor oversights: skipped hostname checks, disabled certificate validation in staging, token reuse, or mobile apps that silently trust any cert.

But the good news? The tools to prevent these attacks are well-established and widely available. With the right mindset and configurations, MITM risks can be dramatically reduced, or even eliminated.

Security shouldn’t be something you patch on. It should be designed into your architecture from the start, just like authentication and authorization.

Many MITM attacks exploit weaknesses in session handling and identity flow. If you're building secure, enterprise-ready authentication into your product, WorkOS gives you developer-friendly building blocks to do it right:

• OAuth2 with PKCE for secure client-side flows.
• SSO with robust TLS enforcement across identity providers.
• Audit logs to help monitor and validate traffic integrity.

WorkOS handles the edge-case complexity, so you can focus on shipping secure features faster. Sign up today.