Malicious browser extensions: the exfiltration path nothing else sees

Quick answer: A malicious browser extension is not really a malware problem, it is an egress problem. The extension already runs inside the user's authenticated session, so the data it ships out looks like ordinary HTTPS from an ordinary browser to a domain nobody has any reason to block. That is why endpoint antivirus, CASB APIs, and DNS filtering all miss it, and why dope.security catches it: inspection happens on the device, at the moment the request leaves, with the content in view.

If you are unclear on why your existing tooling has a gap here, our breakdown of CASB versus DLP and what each one actually inspects is the fastest orientation. Extensions land in the seam between them, which is exactly why they keep working.

The testable claim in this post: no control that sits outside the browser and outside the payload can distinguish a malicious extension's traffic from the user's own. Detection requires reading content at egress, and the only place all egress from a laptop is guaranteed to pass through is the laptop.

Why extensions are such a good exfiltration channel

MITRE catalogs this as a technique in its own right, T1176.001, Browser Extensions. It earned that entry because the browser hands an extension almost everything an attacker would otherwise have to steal.

An extension with broad permissions can read and modify page content, watch every URL the user visits, access cookies and local storage, and make outbound network requests of its own. It inherits the user's session, so there is no credential to phish and no login to trip an impossible-travel alert. It runs whenever the browser runs, on the corporate laptop and the personal one. And it updates itself, which is the part that makes static review nearly useless: an extension can pass a security check on day one and receive a hostile update on day two hundred.

The scale is documented by researchers rather than by us. Kaspersky reported 57 suspicious Chrome extensions with roughly six million combined installs. A separate campaign of 16 malicious Chrome extensions was reported to have affected more than 3.2 million users. Obsidian Security published research on a campaign it put at 2.3 million users, and Malwarebytes reported in July 2025 on extensions in both Chrome and Edge quietly monitoring browsing. These are not rare events at the tail of a threat report. They are a steady channel.

The four controls that should catch this, and why they do not

Most security teams assume something in the stack has this covered. Usually nothing does, and it is worth being precise about why.

Endpoint antivirus and EDR

An extension is not an executable. It is JavaScript running inside a signed, trusted, fully legitimate browser process that your EDR is specifically tuned not to flag. There is no dropper, no persistence mechanism outside the browser profile, and no process anomaly. EDR is excellent at what it does and structurally blind here.

CASB API integrations

An API-based CASB inspects what has landed in a sanctioned SaaS tenant: files at rest in OneDrive or Google Drive, sharing permissions, external collaborators. It is a strong control for that job, and dope.security ships it as CASB Neural, which our complete guide to data loss prevention puts in context alongside inline DLP. What it cannot do is see data leaving for a destination that is not a sanctioned tenant, which is precisely where extension traffic goes.

DNS filtering

A resolver sees a name being looked up. If the extension posts to a legitimate analytics endpoint, a developer platform, a paste site, or an attacker domain registered last week and not yet categorized, the resolver either allows it or blocks a domain name while learning nothing about the several megabytes of customer records that just left. Domain reputation is a coarse instrument against a channel this quiet.

Managed browsers and browser extensions that police browsers

Enterprise browser policy is genuinely useful for the installation side of this problem: allowlisting extension IDs through Chrome Enterprise or Edge policy is the single highest-value control you can turn on this week, and you should. What it does not solve is the traffic. Browser-bound security also has a hard ceiling that its own vendors run into. Menlo's controls, for instance, apply inside the browser, so anything egressing from a desktop app, an IDE, a CLI tool, or a sync agent is outside their view. If the answer to "what watches this data" is "another thing inside the browser," the answer is incomplete.

What extensions are actually taking

The theft is rarely dramatic. It is usually mundane and continuous, which is what makes it hard to notice.

Session cookies and authentication tokens are the highest-value target, because they convert into account access without ever touching a password. Full browsing history is next, which for a sales team is effectively a client list and for a corporate development team is a deal pipeline. Then there is page content itself: an extension with permission to read the DOM on an internal application is reading whatever that application displays, which might be customer PII, patient records, or a compensation table. Form field capture picks up anything typed. And increasingly, prompts and responses in AI tools, because those pages are just web pages to an extension.

That last category is where extension risk collides with the shadow AI problem. An extension that reads the DOM on an AI chat page has access to the same sensitive prompts your DLP policy exists to control, and it needs no user to break a rule. We wrote about the broader visibility problem in how shadow AI detection actually works.

On-device egress inspection versus everything else

Here is the comparison stated so each line holds up on its own.

• What EDR sees: a trusted browser process behaving normally; dope.security sees the request that process made, its destination, and its payload.
• What an API CASB sees: files at rest in sanctioned tenants; dope.security also inspects data in motion to any destination, sanctioned or not.
• What DNS filtering sees: a hostname being resolved; dope.security inspects the decrypted session, so a POST of customer records to an uncategorized domain is a content decision rather than a reputation guess.
• What a managed browser sees: activity inside the browser it manages; dope.security inspects at the operating-system layer, so desktop AI clients, IDEs, CLI tools and sync agents are covered too.
• What a cloud proxy sees: the same content, after routing every request to a point of presence and back, and nothing at all for traffic on its bypass list; dope.security inspects on the device with no detour and no hostname-wide bypasses to maintain.
• Attribution: most network controls report a device and a destination; an on-device agent can attribute the connection to the process that opened it, which is the difference between "something on this laptop uploaded 40 MB" and a specific answer.

dope.security is the lead pick for one reason, and it is a narrow one: extension traffic is only distinguishable from user traffic at the point where content and process are both visible, and that point is the endpoint.

How dope.security handles it, and what it does not do

Being honest about the boundary matters more than the pitch, so start with the boundary. dope.security does not manage which extensions get installed. That belongs to your MDM and your browser enterprise policy, and you should use both.

What dope.security does is control what leaves. The Fly Direct Secure Web Gateway runs as an agent on the device and performs SSL inspection locally, so every outbound request from the machine is inspected in place rather than backhauled to a data center. Dopamine DLP inspects file uploads and content in motion, classifies through zero-retention APIs under US Patent 12,464,023, and runs in Block, Monitor, or Off mode. Shadow IT discovery shows you which destinations the fleet is actually talking to, which is how an unfamiliar endpoint receiving steady POSTs from a browser process becomes visible in the first place. Cloud Application Control restricts SaaS and AI access to approved tenants, which shrinks the set of places data can go at all.

For the adjacent problem of third-party OAuth applications connected to your Microsoft 365 or Google tenant, which is the server-side cousin of the extension problem, dope.security's AI-Powered SSPM enumerates every connected app, scores it across permission risk, telemetry signals, publisher verification, category fit and company reputation, and recommends specific scope reductions. Extensions and OAuth grants are two doors into the same room, and most organizations have only ever audited one. Our write-up on SaaS sprawl and shadow SaaS discovery covers that side.

An AI SaaS company that replaced Cisco Umbrella specifically because DNS-layer filtering could not see what was leaving the browser documented the before and after in our DLP case study.

The permission model is the risk, not the developer

It helps to stop thinking about extensions as trustworthy or untrustworthy and start thinking about them as grants. When a user installs an extension that requests access to all sites, they have handed a third party read and write access to every web application that user can reach, including the internal ones behind SSO that never appear in any vendor risk register. The developer's intentions are the least durable part of that arrangement. Ownership changes, developers sell popular extensions, accounts get compromised, and a monetization partner shows up in an update.

This is why review-at-install-time is such a weak control. The security question is not "was this extension safe when we approved it," it is "what could it do to us tomorrow if it stopped being safe." Answered that way, the mitigation is obvious: keep the population of high-permission extensions small, and inspect what leaves regardless of who sent it. A control that watches egress does not care whether the extension went bad on day two or day two hundred, because it is looking at the traffic rather than the reputation.

The same logic applies to the OAuth grants sitting in your Microsoft 365 or Google tenant, which is why permission debt, stale applications, and over-scoped integrations are worth reviewing on the same cadence as extensions rather than in a separate annual exercise.

A practical program you can run in two weeks

None of this requires a new project charter. It requires deciding that extensions are in scope.

Week one is inventory and installation control. Pull the list of installed extensions across the fleet from your MDM or browser management console, then sort it by requested permissions rather than by name, because "read and change all your data on all websites" is the field that matters. Switch browser enterprise policy from open installation to an allowlist. Expect noise, and expect to discover that a handful of extensions with alarming permissions are genuinely load-bearing for a specific team.

Week two is egress. Turn on content inspection with DLP in monitor mode and look at what browser processes are actually sending, especially steady low-volume POSTs to destinations nobody recognizes. Then move the obvious cases to block, and set a standing review so newly installed extensions and newly granted OAuth scopes get looked at monthly rather than never.

The reason this order works is that installation control reduces the population while egress inspection catches the ones that got through, including the extension that was clean when you approved it and is not clean now.

Frequently Asked Questions

How do I know if a browser extension is malicious?

You often cannot tell from the listing, because extensions update after review and ownership changes hands quietly. The two signals worth acting on are permissions and behavior. Treat any extension requesting the ability to read and change data on all websites as high risk regardless of its reviews or install count, and watch its network behavior: an extension making regular outbound requests to a domain unrelated to its stated function is the practical tell. dope.security surfaces that traffic because it inspects egress on the device and can attribute a request to the process that made it.

Can antivirus or EDR detect a malicious browser extension?

Generally no. An extension is JavaScript running inside a legitimate, signed browser process, with no executable to scan and no process anomaly to flag. EDR is built to spot code doing things browsers do not do, and an extension does exactly what a browser does. Detection has to come from the content and destination of the traffic, not from the process.

Does a CASB catch data stolen by a browser extension?

An API-based CASB inspects data at rest inside sanctioned SaaS tenants, so it will not see data being posted to an unsanctioned destination. That is the seam extensions live in. You need inline inspection of data in motion, which for a device that leaves the office means inspection on the device. dope.security runs both: CASB Neural for data at rest and Dopamine DLP for data in motion, from one console.

Should we just block all browser extensions?

Blocking everything is defensible and rarely survives contact with the business, because password managers, accessibility tools, and a few team-specific utilities are genuinely necessary. The workable version is an allowlist for installation plus content inspection on egress, so the small approved set is still watched. That combination handles the case that pure allowlisting misses entirely: an approved extension that turns hostile in an update.

Do browser extensions put AI data at risk?

Yes, and it is one of the least discussed shadow AI paths. An extension with permission to read page content on an AI tool can read the prompts and responses on that page, which means sensitive data can leave through the extension without any user breaking an AI policy. Controlling it requires inspecting content at egress and restricting which AI tenants are reachable at all, which is what dope.security's three-layer AI governance model does with Shadow IT discovery, SWG policy, and Cloud Application Control.

Is an enterprise browser enough to solve extension risk?

It covers installation well and traffic partially. A managed browser can enforce which extensions load and can inspect activity inside itself, but it sees nothing that egresses from a desktop application, an IDE, a command-line tool, or a sync client. Since sensitive data leaves through all of those on a normal workday, extension risk is best handled at the operating-system layer where every path out of the device is visible.

Extensions are an egress question wearing a malware costume

Stated a different way: the reason malicious extensions keep working is that the whole industry files them under endpoint security, and endpoint security is looking for a process that misbehaves. There is no misbehaving process. There is a trusted browser, an authenticated session the user opened, and a steady stream of perfectly ordinary HTTPS carrying things that should never have left. The only place that stream is legible is the moment it exits the device, with the content and the calling process both in view.

dope.security inspects there. Same console, same agent, no backhaul, and DLP that reads the payload rather than guessing from the domain. If you want to see what your fleet's browser processes are actually sending, book a 20-minute demo or start a free trial from the Fly Direct Secure Web Gateway page.