A Man-in-the-Browser attack occurs when malware infects a web browser, allowing it to modify web pages, transaction content, or insert additional transactions in a covert fashion. These attacks are particularly dangerous as they can bypass many traditional security controls including HTTPS and two-factor authentication.
A man-in-the-browser (MitB) attack relies on malware, often a trojan or a malicious browser extension, that installs itself inside the victim's browser. Once resident, it hooks into the browser's functions so it can read and rewrite pages as they are displayed and as data is submitted. During an online banking session, for example, the malware can show the user the amounts and recipients they expect while silently altering the transaction actually sent to the server, or inject extra form fields to harvest credentials. Because the tampering happens after decryption, inside the trusted browser, the manipulation is invisible both to the user and to the server receiving the request.
MitB defeats controls that assume the browser itself is trustworthy. The connection is still valid HTTPS, so encryption does not help; the session belongs to the legitimate user, so server-side authentication passes; and because the malware manipulates the live session in real time, it can defeat many one-time-password and two-factor schemes by riding an already-authenticated session. The user sees a normal, correct-looking page while different data reaches the backend. This makes MitB a favorite for financial fraud and account takeover, and it can persist across sessions until the underlying infection is found and removed from the device.
Because the malware lives on the victim's own device, endpoint hygiene is central: up-to-date anti-malware, cautious extension installation, and prompt patching. Server-side, out-of-band transaction verification, showing the real details on a separate channel such as a mobile app or SMS, lets users catch amounts that were altered in the browser. Note the capability ceiling: an infection in the visitor's own browser sits outside the scripts a site loads, so a third-party-script monitor cannot clean it. cside is relevant to the adjacent case where manipulation arrives through a compromised third-party script or injected code on your pages; it analyses those payloads at a Script method and can block the malicious behavior in real time.
No. HTTPS secures data in transit between the browser and server, but a man-in-the-browser attack operates inside the browser, after the page is decrypted and before a submission is encrypted. The channel stays valid while the content is tampered with, so the padlock offers no protection here.
A man-in-the-middle attacker intercepts traffic on the network path between browser and server, which HTTPS largely defeats. Man-in-the-browser sits inside the endpoint itself via malware, so it sees and edits data that is already decrypted. That placement lets it bypass encryption and many two-factor checks entirely.
We answer client-side security questions every day. Bring yours.