What is a man in the middle attack when the middle sits between your user and your web app? Someone on the network path reads or changes the traffic as it passes. HTTPS with a valid certificate stops that, but 3 gaps stay open: the first plain-HTTP request, a cookie without Secure, and a proxied login page.
Man in the middle attack: what it is, in one paragraph and one picture
A man-in-the-middle attack is a third party secretly relaying the traffic between two others who believe they are talking directly. The attacker needs a position on the network path and a way past encryption. Reading the traffic is the passive form, and changing it on the way through is the active form.
For a web app, the two parties are a user’s browser and your server, and the relay is whoever controls a piece of the route between them. In cyber security the term is precise, and Microsoft’s DigiNotar advisory puts it in one sentence: “A man-in-the-middle attack occurs when an attacker reroutes communication between two users through the attacker’s computer without the knowledge of the two communicating users.” That makes it one piece of web app security, the piece that happens on the wire rather than in your code.
MITM is the abbreviation, so a MITM attack carries the same meaning, and “middle man hacking” is the plainer phrase for it. OWASP now files the attack under a newer name on OWASP’s manipulator-in-the-middle page, where the attacker splits one connection into two and acts as a proxy, “being able to read, insert and modify the data in the intercepted communication.”
For an app owner, the useful explanation of a man-in-the-middle attack is two conditions that every form needs (my framing). The first is a position on the path: the same Wi-Fi as the victim, a poisoned DNS answer, a compromised router, or a proxy the user was tricked into visiting. The second is a way past encryption: there is none to get past, the connection is pushed down to plain HTTP, the victim’s device trusts a certificate it should not, or the attacker takes the session after the encrypted login has already finished.
Drawn as a man-in-the-middle attack diagram, the path has two lanes. On plain HTTP, headers and payloads travel in cleartext, so the party in the middle reads and edits everything. On HTTPS, data after the handshake “is only visible to the endpoints” and cannot be changed without detection, yet TLS does not hide the length of what it sends, and RFC 8446 says it is open to traffic analysis based on “the length and timing of encrypted packets.”
Plain HTTP
browser ──► party in the middle ──► server
reads and changes every request
and every response
HTTPS
browser ──► party in the middle ──► server
sees encrypted records and their
length and timing, not the contentMeet-in-the-middle attack: a different thing with a similar name
A meet-in-the-middle attack is cryptanalysis, not network interception. It attacks a cipher applied twice with two keys by working forward from the plaintext and backward from the ciphertext until the results match, which is why double encryption adds far less strength than its doubled key length suggests.
The technique comes from Whitfield Diffie and Martin Hellman’s 1977 paper “Exhaustive Cryptanalysis of the NBS Data Encryption Standard.” Encrypting twice with two independent 56-bit keys “would hopefully yield” a much longer key, they wrote, but a “meet in the middle attack” needs work on the order of 2 to the power 56 in time and memory: encrypt the plaintext under every first key, decrypt the ciphertext under every second key, and keep only the pairs that land on the same middle value. Their advice was that multiple encryption should use at least three passes. Triple DES took that shape: NIST’s standard defines its key as three DES keys. It has since been retired: NIST SP 800-67, its recommendation, was withdrawn on January 1, 2024, and its last revision already said two-key triple DES “shall not be used to apply cryptographic protection.”
So a meet in the middle attack and a man-in-the-middle attack are not the same thing: one recovers keys from a cipher’s math, the other sits on live traffic. Nothing about the cipher attack involves intercepting a connection. The only action for an app owner is one you already take for other reasons: use the TLS versions and cipher suites your host ships by default, and never write your own encryption.
Why it matters for a small web app: where the attack is possible, and the 3 gaps HTTPS leaves
HTTPS with a valid certificate stops a man-in-the-middle attack on the connection itself. Three gaps remain for an app owner to close: the first plain-HTTP request before the redirect, a session cookie sent without the Secure flag, and a look-alike login page that relays the real one, where HTTPS is valid on both legs.
A man-in-the-middle attack is possible anywhere between the two ends, and for a small web app that means four places (my reading):
- The user’s local network: a shared Wi-Fi, a hotel network, or a router someone has taken over.
- The DNS answer: whoever answers “where is this domain?” first decides where the browser goes.
- The path between your server and the APIs it calls, which carries your keys and your users’ data.
- The user’s own device, when it trusts a certificate it should not.
RFC 8446, the TLS 1.3 specification, lists what an encrypted connection should give you: “The server side of the channel is always authenticated”, data is visible only to the two ends, and it “cannot be modified by attackers without detection.” The RFC says those properties should hold even against an attacker with complete control of the network. Turning that promise into a configured app is the work of man-in-the-middle prevention for a web app; this section stays on the attack side and names what gets through anyway.
| Gap | What the attacker gets (my reading) | Why HTTPS alone does not close it | Where the fix lives |
|---|---|---|---|
| 1. The first plain-HTTP request | The chance to answer before the redirect and keep the user on HTTP (SSL stripping) | A redirect travels over the plain request, and an on-path attacker “can intercept and re-write the redirect to keep the browser using plaintext HTTP”; RFC 6797 calls the first visit the bootstrap MITM vulnerability | The HSTS header; the redirect and the certificate |
2. A session cookie without Secure | The session cookie, read off any plain-HTTP request | Only a cookie marked Secure is limited to requests made with the https: scheme | Session cookie attributes |
| 3. A proxied look-alike login | The password, a code typed into the relay, and the session cookie that follows | The certificate is valid for the look-alike domain, so both legs are real HTTPS | Origin-bound passkeys, under two-factor for owner and admin accounts |
RFC 6797, the HSTS specification describes the first gap plainly: when a user types an “http” address for a site the browser has never seen, “such an initial interaction is vulnerable to various attacks.” The fixes for it are the HSTS header and the other production security headers, plus the redirect and certificate steps to add HTTPS to a website. Browsers have narrowed the gap on their own: hstspreload.org notes that many browsers, naming Chrome and Safari, “will automatically upgrade all HTTP navigations to HTTPS, regardless of the domain’s HSTS policy,” and that preloading only adds value when those upgrades fail in the presence of an active attacker.
The second gap comes down to one attribute. MDN’s Set-Cookie reference says a Secure cookie “is sent to the server only when a request is made with the https: scheme (except on localhost), and therefore, is more resistant to manipulator in the middle (MITM) attacks.” Expiry, rotation and the rest belong to session and token controls.
The third gap is the one HTTPS was never built to catch, because the user really is talking to a server with a valid certificate, just the wrong one. CISA and the FBI recorded ransomware affiliates using an open source adversary-in-the-middle framework to obtain “multifactor authentication (MFA) credentials, login credentials, and session cookies.” A code typed into a relay is a code the relay can use. The login only binds to the real domain when the credential does, which is why origin-bound passkeys are the fix under two-factor authentication for owner and admin accounts.
Here is how the first gap plays out as a case. A founder’s app runs on a custom domain that redirects plain HTTP to HTTPS, sends no Strict-Transport-Security header, and sets its session cookie without the Secure attribute. A user who is already signed in types the bare domain on a hotel network. The browser’s first request goes out over plain HTTP, someone on that network can answer it before the real redirect arrives, and the session cookie rides along on that plain request. HSTS lets the browser skip that plain request on later visits, though the RFC itself names the first visit as the limit, and a cookie marked Secure would never have left over plain HTTP at all. The lesson I take from it: a redirect to HTTPS protects every request after the first, and the first one belongs to whoever answers it, unless the browser already knows to skip it.
Across the third-party apps I audited in June and July 2026, the Authentication pillar averages 52.8 out of 100, scored on 14 of the 21 third-party apps. Those apps are a selected set, not a random sample, so the figure says nothing about AI-built apps in general. All three gaps sit in what happens around login, which is where that pillar is scored (my reading).
How it works: the two stages, the seven types, real cases, and the tools
Four parts follow: the steps of the attack, the types (with the main table on this page), cases with a primary source, and the tools.
How a man-in-the-middle attack works, stage by stage
A man-in-the-middle attack runs in 4 steps: get on the path between the two parties, get past the encryption or avoid it, relay the traffic so neither side notices, and use what passed through. The second step is the only one an app owner controls.
Seen from the network path, man-in-the-middle attacks work in the same four steps every time (my framing):
- Get on the path. Join the same network, answer a DNS or ARP question before the real owner does, or get the user to visit a look-alike address.
- Get past the encryption. On a plain-HTTP site there is nothing to do. Otherwise, keep the user on HTTP by answering the first request, present a certificate the device wrongly trusts, or skip the problem by relaying the real HTTPS site from a look-alike domain.
- Relay so neither side notices. The page loads, the login works, the user moves on.
- Use what passed. Credentials, the session cookie, a changed payee on a transfer, or a changed file on a download.
Norton’s explainer splits the attack into “two phases: interception and decryption,” which match steps 1 and 2 here. Step 2 is where an app owner has any say, and it takes three settings, not a product: the HSTS header, the Secure cookie flag, and credentials bound to your domain.
Man in the middle attack types, and which ones reach an app on HTTPS
Man-in-the-middle attack types come to 7 that touch a web app: rogue Wi-Fi, ARP spoofing, DNS spoofing, SSL stripping, session hijacking, proxy phishing and a forged or wrongly trusted certificate. HTTPS with a valid certificate stops the first three, partly stops the next two and does not stop the last two.
The types of man in the middle attacks below are read from the server’s side. Reading traffic is passive and changing it is active, and the “stopped by HTTPS” column is my reading of the RFCs, MDN and the WebAuthn specification, and is labeled that way.
| Type | Where the attacker stands | Passive or active | Stopped by HTTPS plus a valid certificate (my reading) | What lets it through | Where the fix lives |
|---|---|---|---|---|---|
| Rogue or evil-twin Wi-Fi | On the user’s wireless network, or on a similarly named access point | Either | Yes, unless gap 1 or 2 applies | A first plain-HTTP request, or a cookie without Secure | The HSTS header; session cookie attributes |
| ARP spoofing | On the same local network as the user | Either | Yes, unless gap 1 or 2 applies | The same two gaps | The HSTS header; session cookie attributes |
| DNS spoofing or a hijacked DNS record | In the answer to the DNS lookup | Active | Yes: a server that cannot present a valid certificate for your domain draws a browser warning | Control of your domain’s DNS account itself, an account-security problem | Registrar lock and a CAA record |
| SSL stripping | On the path during the first request | Active | Partly: if the site sends HSTS, every visit after the first | The first visit, before the browser knows the HSTS policy | The HSTS header |
| Session hijacking by cookie theft | On the path, reading a plain-HTTP request | Passive, then active | Partly: only when the cookie is marked Secure | A session cookie without Secure | Session cookie attributes |
| Adversary-in-the-middle phishing through a reverse proxy | On a look-alike domain the user was lured to | Active | No: HTTPS is valid on both legs | The user signs in on the wrong domain | Origin-bound credentials (passkeys) |
| A forged or wrongly trusted certificate | At a certificate authority that issued a bad certificate, or in a root certificate installed on the device | Active | No: the browser trusts the certificate | A compromised authority or software that adds its own root | A CAA record and Certificate Transparency monitoring |
For a man in the middle attack over Wi-Fi, the app-side answer is the same two settings as gaps 1 and 2. MITRE ATT&CK’s Adversary-in-the-Middle technique, T1557, is the reference catalog entry for the whole family, and it lists four sub-techniques, among them ARP Cache Poisoning and Evil Twin. The registrar lock and CAA record for the DNS row are part of adding HTTPS to a website, covered above.
The proxy-phishing row is the one where a code by text or app fails, and the WebAuthn specification shows why passkeys hold: the authenticator ensures that credentials created by a site “can only be used in operations requested by the same RP ID.” A relay on another domain has a different RP ID, so the passkey never answers it. The certificate row needs a watcher, because a certificate authority “that has been hacked or sloppy can issue certificates for any website,” in the words of the Certificate Transparency project.
Email hijacking is a different path: it runs through the mail system, not your app’s connection, and its defense is SPF, DKIM and DMARC setup.
Man-in-the-middle attack examples that actually happened
Man-in-the-middle attack examples with a primary source include DigiNotar in 2011, where a certification authority issued fraudulent certificates and Microsoft revoked trust in its root certificates, and Superfish, software Lenovo preinstalled on some consumer PCs that intercepted and decrypted HTTPS traffic, which CISA flagged in 2015.
| Case | Year | Type | What the source says happened |
|---|---|---|---|
| DigiNotar | 2011 | A forged or wrongly trusted certificate | Microsoft’s advisory: attacks used “at least one fraudulent digital certificate issued by DigiNotar”, which “could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against all Web browser users”; an update on September 13, 2011 revoked trust in DigiNotar’s root certificates |
| Superfish on some Lenovo PCs | Preinstalled from September 2014; CISA alert February 20, 2015 | A wrongly trusted certificate | CISA’s alert: the software installed its own trusted root certificate, and all browser-based encrypted traffic was “intercepted, decrypted, and re-encrypted”, which CISA called “a classic man-in-the-middle attack” |
| ALPHV Blackcat affiliates | Advisory of December 19, 2023 | Adversary-in-the-middle phishing | CISA and FBI advisory AA23-353A: affiliates used an open source adversary-in-the-middle framework to obtain MFA credentials, login credentials and session cookies |
Microsoft Security Advisory 2607712 is the record for DigiNotar, the plainest example of a MITM attack that could reach any web browser user. DigiNotar sat in the Windows Trusted Root Certification Authorities Store, which is why the fix was to revoke trust in its root certificates rather than patch a product. CISA’s Superfish alert adds the detail that made the second case worse: the private key “can easily be recovered from the Superfish software,” so anyone could mint certificates those machines would trust. The lesson I take from both: the sites involved did nothing wrong at the connection level, because the trust broke upstream, at an authority or on the device. Watching what gets issued for your domain catches the first kind; the second lives on the user’s machine, beyond any server setting.
Tampering with a package before install reaches a similar result by another route, and npm malware packages and what the incidents did is its own subject. A server that pulls code from a remote URL at run time has the same trust problem seen from the other side, the old one behind remote file inclusion.
Man in the middle attack tools: what exists, and why that matters to you
Man-in-the-middle attack tools are mostly the same free programs developers use for debugging: an intercepting proxy and a packet analyzer are the two main kinds. Their availability means an unencrypted connection takes little skill to read, so encryption and the three settings carry the whole defense.
mitmproxy describes itself as “a free and open source interactive HTTPS proxy” and as “your swiss-army knife for debugging, testing, privacy measurements, and penetration testing.” Wireshark calls itself “a powerful, open-source network protocol analyzer that allows users to capture and interactively browse the traffic running on a computer network.” None of this man-in-the-middle attack software is secret or new, and OWASP notes that MITM “is also commonly used during web application development and vulnerability assessments.”
What that means for you (my reading): the attack needs little skill on an unencrypted connection, so “nobody would bother” is not a defense. The one use that belongs on an app owner’s list is pointing an intercepting proxy at your own app, on your own device, to see what it sends, including whether any request leaves over plain HTTP. Testing of that kind, on systems you own or have written permission to test, is pen-test ground, and what a pen test is and who is asking for one sets the boundary before any tool runs.
How to check your own app: detection from the server’s side
Man-in-the-middle attack detection from the server’s side is 5 checks: the plain-HTTP request redirects, the HSTS header is present, the session cookie carries Secure and HttpOnly, an external TLS scan returns the top grade, and the Certificate Transparency log shows only issuers you expect. A passive listener cannot be seen directly.
A server cannot see someone quietly reading traffic on a user’s network, so detection for an app owner means two things: checking from outside that the gaps are closed, and watching your own logs for the traces a relay leaves. Fixing a failed check is man-in-the-middle prevention for a web app, done in the settings each check names; the checks here run from outside, from any laptop.
These checks cannot detect a MITM attack in progress; they show whether one would work. I describe them from RFC 6797, MDN, hstspreload.org, the SSL Labs rating guide and RFC 8659, and each one says what pass looks like and what to keep as evidence. Checks 1 and 2 need only these two requests, with your own domain in place of the example:
curl -s -o /dev/null -D - http://example.com
curl -s -o /dev/null -D - https://example.com- 01 Read the status line and the
Locationheader from the plain-HTTP request. Pass: a permanent redirect, 301 or 308, to the same host onhttps://. Fail: a page served over HTTP, or a first hop to a different host. The short message some hosts put in the redirect body does not matter. Keep the output with the date. - 02 Read the headers from the HTTPS request. Pass: a
Strict-Transport-Securityheader with a longmax-age. Fail: no header, ormax-age=0. AddincludeSubDomainsonly once every subdomain answers on HTTPS; preloading is optional and never the pass condition. Keep the header. - 03 Where the app keeps its session in a cookie, open the browser's developer tools, log in with your own test account, and read that cookie's row (in Chrome: Application, then Storage, then Cookies). Pass:
SecureandHttpOnlyset and aSameSitevalue present. Fail: any of the three missing. If the auth library keeps the session in browser storage instead, record that; this check does not apply. Keep a screenshot of the test account's row. - 04 Run an external TLS scan on the domain and read the grade, the protocol versions and the certificate chain. Pass: the top grade with nothing older than TLS 1.2 offered. Fail: a capped grade, TLS 1.0 or 1.1 on offer, or an incomplete chain. Keep the report.
- 05 Search a Certificate Transparency log for your domain and compare the issuers with the ones you expect, then confirm a CAA record exists and names your host's certificate authority. Pass: only expected issuers, and a CAA record that allows your host's authority. Fail: an issuer you do not recognize, or a CAA record that leaves your host's authority out, which blocks your own renewals. Keep the issuer list and the record.
Hosts differ on the redirect code: Vercel answers plain HTTP with a 308 and sends a Strict-Transport-Security header on custom domains by default. Both 301 and 308 are permanent redirects in MDN’s table. For the max-age in check 2, the HSTS preload list asks for at least 31536000 seconds, one year, from sites that want to be preloaded. The same site says of preloading itself: “While HSTS is recommended, HSTS preloading is not recommended,” and its first deployment step is to examine every subdomain and make sure it works over HTTPS. Look the domain up there only if you did preload; inclusion “cannot easily be undone.”
The scanner for check 4 is Qualys SSL Labs, and its rating guide caps the grade at B when a server supports TLS 1.0 or 1.1 and at A- when TLS 1.3 is missing. For check 5, Certificate Transparency lets domain owners “see which CAs have issued which certificates, when, and for which domains,” and its monitors page lists search tools such as Sectigo’s Certificate Search. RFC 8659 says that once a CAA record exists, a compliant authority must not issue a certificate the record does not allow, unless an exception in its own published policy applies. Vercel issues through Let’s Encrypt, so a Vercel app with a CAA record needs 0 issue "letsencrypt.org" in it.
The signs of a man-in-the-middle attack worth alerting on show up in your own logs (my reading):
- One session used from two distant locations within minutes.
- A login followed at once by a change of email, payout details or API keys.
- A burst of logins from one address across many accounts.
Your users see different signs: a certificate warning, a site that suddenly loads over HTTP, a connection that drops and comes back. They are worth a line in your support replies, because users notice them and you do not. If a check fails and your logs show signs of misuse, start with what to do in the first 30 minutes after an app is hacked before changing any setting.
Checks 2 and 4 mirror how the Production Hardening Sprint verifies two of its deliverables. Deliverable 3.4 is verified this way: inspect response headers and exercise the application to confirm intended protections without broken flows. Deliverable 7.13 is verified this way: pass an external TLS scan at the top grade and file a DNS record export in the runbooks.
Where the sprint fits
No single deliverable is named for man-in-the-middle attacks; five cover the ground. For deliverable 3.4, we configure and test CSP, HSTS, framing restrictions, and other appropriate browser security headers. Under 7.13 we enforce HTTPS everywhere with HSTS and a CAA record, lock the registrar, document the DNS records, and confirm renewal ownership. Deliverable 1.2 is where we verify expiry, refresh, and session revocation on logout and password change. For 1.11 we enforce a second factor on every owner and admin account, in the application and on every provider dashboard behind it, with recovery codes stored in the owner’s vault. The targeted external penetration test, deliverable 3.10, is where we test the five highest-risk externally reachable attack surfaces, remediate findings, and deliver the methods and evidence. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. Each one is listed in the published scope.
Common questions about MITM attacks
What is MITM called now?
It goes by two newer names: OWASP calls it a manipulator-in-the-middle attack, and MITRE ATT&CK catalogs it as Adversary-in-the-Middle, technique T1557. hstspreload.org, for one, simply says “on-path attacker.” In my reading, AiTM most often refers to the proxy-login form, where a look-alike domain relays the real sign-in page.
What’s the difference between MITM and phishing?
Phishing is how a user is lured; a man-in-the-middle attack is a position on their traffic. The proxy-login form is both at once: a phishing link sends the user to a look-alike domain, and the page there relays the real login so the password, the code and the session all pass through.
Who is typically targeted by MITM attacks?
Anyone whose login or session is worth money to someone else. For an app owner, that means the owner and admin accounts first, then any user who can move money or export data, because one relayed admin session opens everything behind it (my reading).
Does a VPN protect you from a man-in-the-middle attack?
Only partly: a VPN protects the hop from the user’s device to the VPN server and nothing after it. It also moves the trust to the VPN provider, and it does nothing against a relayed login page on a look-alike domain, as I see it. An app owner cannot require users to run one and should not rely on it.
What is the most common man-in-the-middle attack?
For an app already on HTTPS, the one to watch first is the relayed login page, because it is the form a valid certificate does not stop (my reading). I have no primary source that ranks the forms by how often they happen, so I give no number.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase