What Is a Man-in-the-Browser Attack?

A man-in-the-browser (MitB) attack is a form of malware that operates inside a victim’s own web browser — usually as a malicious extension, an injected script, or a compromised plugin — to intercept and alter the data a user sees and submits, without needing to intercept network traffic at all. Because the attack runs after HTTPS has already decrypted the page, it defeats transport encryption entirely: the connection is genuinely secure, but the content flowing through it isn’t trustworthy.

Why it’s different from a network man-in-the-middle attack

A classic man-in-the-middle attack sits on the network path between a client and a server, intercepting traffic as it travels. HTTPS was built specifically to defeat this: with a valid TLS connection, an attacker on the network sees only encrypted bytes, not the actual request or response content.

A man-in-the-browser attack sidesteps that protection by operating on the endpoint rather than the network. It doesn’t need to break TLS, because it runs after decryption — inside the browser process, with access to the page’s live DOM and the ability to modify form fields, inject content, and read or rewrite responses before the user or the page’s own JavaScript ever sees them. The browser’s own certificate validation and encryption work perfectly; the compromise happens one layer up.

How the attack typically plays out

1. Infection. The malware reaches the browser through a malicious or trojanized browser extension, a bundled installer for otherwise-legitimate software, or a vulnerability exploited through a compromised website.
2. Injection. Once installed, it hooks into the browser’s rendering and network layers — commonly by injecting JavaScript into pages the user visits, or by hooking browser APIs directly.
3. Manipulation. When the user visits a target site — historically online banking was the classic target — the malware watches for specific pages (a funds transfer form, for example) and modifies the transaction in the background: changing a destination account number, or silently adding an additional transfer, while displaying the original details the user actually typed back to them on screen.
4. Confirmation bypass. Because the malware controls what the page displays, it can also intercept and alter one-time confirmation codes or step-up authentication prompts, showing the user a fabricated success message while the real request that was submitted differs from what they approved.

The defining trait is that the user’s own browser, on their own trusted device, with a fully valid HTTPS connection to the real site, is the thing lying to them.

Why standard defenses don’t catch it

Most of the web’s standard security mechanisms are aimed at the network or at the server, not at a compromised client:

• HTTPS verifies the connection is private and the server is who it claims to be — it says nothing about whether the browser rendering the page is trustworthy.
• CSRF protections and other XSS-focused defenses guard against a malicious site attacking a legitimate browser, or a malicious script being injected from outside — not against malware the user has already installed, which runs with the same privileges as the browser itself.
• Server-side session validation confirms a request came from an authenticated session, but a MitB attack submits its altered request through that legitimate, authenticated session — from the server’s point of view, it’s indistinguishable from anything else the real user might have clicked submit on.

This is why MitB is treated as an endpoint-security problem rather than a web-application-security problem: the fix has to happen either before infection (keeping the endpoint clean) or through an out-of-band channel the malware can’t touch.

Mitigations

• Out-of-band transaction verification. Confirming a sensitive action (like a bank transfer) through a separate channel — a phone call, a dedicated hardware token, or a push notification to a second device — gives the user a chance to see the actual submitted details somewhere the browser malware can’t intercept or rewrite.
• Hardware-backed authentication. Passkeys and FIDO2 security keys bind authentication to cryptographic operations that happen outside the browser’s DOM, which raises the bar considerably compared to a password or a code the malware can simply read off the page.
• Endpoint hygiene. Since the attack requires code running in the browser, the most direct mitigation is preventing that code from getting there in the first place: restricting extension installation to vetted sources, keeping the browser and OS patched, and using endpoint detection tooling that can catch the malware before it ever touches a banking session.
• Behavioral and device-fingerprint monitoring on the server side can sometimes flag transactions that don’t match a user’s typical pattern, as a secondary layer, though this is a detection measure rather than a prevention one.

The takeaway

A man-in-the-browser attack compromises the browser itself, so it operates after TLS decryption and inside an authenticated session — which means HTTPS, CSRF tokens, and server-side session checks all pass normally while the malware quietly changes what’s actually being submitted. Defending against it means treating the endpoint as the attack surface: keeping malware off the device in the first place, and using out-of-band or hardware-backed verification for anything sensitive enough that a compromised browser shouldn’t be trusted to display it accurately.