Man-in-the-Middle

An attacker positioned on the network path between a client and server - a malicious Wi-Fi access point, a compromised router, ARP/DNS spoofing on a local network - intercepts, reads, or modifies traffic that should have been protected end-to-end. Reports in this category typically describe the conditions that make MITM interception damaging (missing certificate pinning in a mobile app, TLS downgrade acceptance, credentials sent over plaintext HTTP) rather than the interception itself, since the interception requires physical or network-level positioning an external scanner never has.

Demonstrating an actual man-in-the-middle attack requires being positioned on the network path between client and server - something a remote HTTP scan, by definition, is not. What a black-box scan can observe (missing HSTS, cleartext form submission, weak TLS configuration) is a related, narrower question already covered by TLS/header auditing rather than this broader interception-scenario category.

Network-level penetration testing, mobile-app certificate-pinning verification, and TLS/HSTS configuration review all play a role here. The TLS and security-header checks in particular can confirm the preconditions that make interception dangerous, like missing HSTS or weak cipher support, without needing to simulate the interception itself.

Tip: This class is typically found by intercepting traffic with a controlled proxy and observing whether the client actually rejects an invalid, expired, wrong-hostname, or revoked certificate — a passive traffic capture on a supposedly encrypted internal link is the other common discovery path, for the plaintext-transport variant specifically.

Real-World Impact

Man-in-the-middle exposure, broken certificate-chain validation, and credentials sent over an unprotected transport all share the same underlying failure: the connection isn't actually providing the confidentiality and authenticity guarantee the application assumes it is. An attacker positioned on the network path, a compromised Wi-Fi access point, a malicious proxy, a rogue router, can intercept or tamper with traffic that the application believes is safely encrypted end-to-end.

Once that trust assumption is broken, everything the connection carries is exposed: credentials, session tokens, and any sensitive data moving in either direction, with no obvious indication to the user that anything is wrong, since a partially-broken TLS setup can still display as "secure" in a browser depending on exactly what failed.

Certificate-revocation checking gaps are a related but narrower failure: even a properly-validated certificate chain doesn't help if the client never checks whether a certificate was revoked after a private key compromise, which means a stolen and revoked certificate can still be accepted as valid.

Prevention and Secure Design

Preventing Man-in-the-Middle takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Enforce TLS everywhere, with no fallback to plaintext. Every connection carrying credentials or sensitive data — including internal, service-to-service traffic — should require TLS with no unencrypted fallback path.

Validate the full certificate chain, hostname, and revocation status. Chain trust alone isn't sufficient — confirm the hostname matches and check revocation status (OCSP or a current CRL) rather than assuming a presented certificate is still valid just because it was once issued correctly.

Use HSTS to prevent protocol downgrade. HTTP Strict Transport Security tells browsers to never attempt an unencrypted connection to your domain, closing off a common downgrade-attack vector.

Never disable certificate or transport validation, even temporarily. A validation bypass added for debugging or local development is one of the most common ways this class ends up shipped to production.

Pin certificates for high-value, first-party connections. For a mobile app or service talking to its own backend, pinning adds a layer beyond standard CA trust, at the cost of needing a clear certificate-rotation plan.