Manage Browser Extensions by What They Do, Not What They Are

Key Takeaways

• To manage browser extensions centrally, govern what each extension can access and do in the work session, not just whether it's allowlisted.
• An approved extension can change through auto-updates, new permission requests, or a new owner. Re-decide its approval whenever its permissions or behavior change.
• The strongest extension controls live inside the browser session, through site-level restrictions, protected session data, and data-movement controls, so a bad update reaches less.
• Central extension management has to cover unmanaged, contractor, and personal browsers reaching corporate apps. A fast approval process keeps people from routing around it.

An allowlist approves an extension's name, not its next update

In most extension review meetings, a popular productivity tool gets a look and someone checks its permissions. The ID goes on the allowlist, and the team moves on to the next request. Months later, few people remember the conversation, but the extension is still running across the fleet.

Allowlists, blocklists, and force-install lists were the right answer when the question was which software belonged on company endpoints, and they're still the baseline. UK NCSC guidance for ChromeOS tells administrators to block unknown extensions and allowlist trusted ones. It pairs that advice with regular monitoring of updates to allowlisted extensions.

What changed is the software behind the ID. Extensions typically update automatically, and an update can ask for additional permissions. Mozilla's add-on store lets owners transfer an extension to a new owner who then controls its updates, and developer accounts can be phished.

Through all of it, the extension ID stays the same while the code behind it changes.

A peer-reviewed Stanford and CISPA study of the Chrome Web Store, presented at ACM AsiaCCS 2024, puts numbers on the gap. Using 2020–2023 data, the authors found malware-containing extensions stayed in the store for an average of 380 days. Installs of these security-noteworthy extensions reached about 346 million over three years, though those are install counts, not unique users.

The same authors recommend vetting extension updates, since benign extensions can turn malicious after permission changes. The mechanism isn't hypothetical; in January 2025, The Register reported attackers had phished dozens of extension developers through a malicious OAuth app.

The attackers then published compromised versions of legitimate extensions, aimed at session cookies and authentication tokens.

AI chat at work raises the stakes: Pew Research Center reported in June 2026 that 38% of employed U.S. adults use chatbots for work tasks. When those chats happen in a browser, they sit in sessions extensions can read. In December 2025, researchers told The Register privacy-branded extensions were capturing AI chatbot prompts and responses, and one added its consent prompt in a silent update.

Approval is a snapshot; extensions are a feed. So the useful question shifts from whether an extension is approved to what it can do today, and where.

Behavior-based extension management starts with three questions

A large fleet's extension report can run long, well beyond what any review team can hand-inspect after each update. Three questions let you triage that list by risk instead of reading it top to bottom. Together, they're the practical answer to how to manage browser extensions centrally without a review backlog.

1. What can it touch? Start with declared permissions and host access, such as changing data on all sites, intercepting web requests, or reading cookies.
2. Where is it running? Map the apps it can see, since a grammar tool matters more in the finance ERP than on a marketing site.
3. What changed since you approved it? Compare version, permissions, developer or owner, and contacted remote hosts against the approved baseline.

These questions translate into controls enterprise browser policies already expose. Firefox's ExtensionSettings policy, for example, lets admins block extensions by the API permissions they request rather than only by ID. It can also keep extensions from running on designated sensitive sites, which narrows where a broad permission applies.

Permissions are where the blast radius lives. UK NCSC guidance on managing web browser security notes extensions "typically have permissions to read or change the data on any websites a user visits." Broad host access is the first line worth drawing, because it decides how much of the session an extension can read.

Most extension reviews sort by category: productivity, developer tools, shopping, and so on. Category tells you what an extension is for, and very little about what it can reach. A coupon extension with access to all sites can see more corporate data than a niche developer tool scoped to one domain.

So classify extensions by the data they can reach, and set policy on that. An extension with all-sites access and cookie permissions belongs in a different tier from one limited to an internal wiki, whatever its label says. The tiers then drive defaults: broad-access extensions get scoped off sensitive apps, while narrow ones move through review quickly.

Run a fleet through those three questions and it splits into a short list for human review and a long tail governed by rule. That's how central management scales without turning the review team into a bottleneck.

Approval should expire when an extension's permissions change

It's Monday morning, and a trusted extension is asking users across the company to accept a new permission. The help desk queue fills with screenshots, and someone has to decide whether to approve the change company-wide or block a tool people rely on. Most teams make that call under pressure, with little context about what the new permission unlocks.

A cleaner model treats a meaningful change as a new extension, with a new decision. These events should reopen an approval automatically:

• New permissions or broader host access requested in an update
• Change of developer, publisher, or owner
• New remote domains contacted or code loaded remotely
• Removal from the store or a policy-violation flag
• Long dormancy followed by a sudden update

Ownership changes deserve the closest look, because the extension ID survives a sale intact. In one documented case reported by BleepingComputer in February 2026, an extension was sold through a marketplace. The new owner's update requested new browser permissions and delivered malicious payloads.

One case isn't a trend, but it shows how little an extension ID tells you after a sale. The name, the icon, and the store listing can stay familiar while the intent behind them changes completely.

Version pinning looks like the safe response, and for most fleets it trades one risk for another. The Stanford and CISPA study found 60% of Chrome Web Store extensions had never been updated as of February 2023. The same study found about half of known-vulnerable extensions were still vulnerable two years after disclosure, and freezing a version doesn't fix that.

UK NCSC guidance also advises keeping automatic updates on for both the browser and its extensions. Pinning works against that advice, and it quietly turns the review team into the patch team.

The better gate is the permission and behavior delta. Let routine updates flow, and automatically quarantine or disable an update that expands access until someone decides. Bug fixes and performance patches keep arriving on schedule, while the rare update asking for more gets a human look.

That decision needs an owner. Without one, "pending review" becomes a polite phrase for "blocked forever," and people find their own workarounds.

The safest place to contain an extension is inside the session it can see

Even with a disciplined review process, your team will eventually miss a compromised update for a few hours or a few days. When that happens, what matters most is how much of the work session the extension can reach.

Where the controls live determines the answer, because each layer sees a different slice of the session. An enterprise browser with native controls can govern extension behavior, session data, and data movement directly, since the controls are part of the browser. An extension-based layer on consumer browsers extends visibility and policy to the browsers you aren't replacing, which makes it a practical complement for mixed fleets.

Network and proxy controls see the traffic leaving the browser, though not what an extension does inside the page. They remain valuable for the job they were built to do, and in-page extension behavior simply sits outside their view.

Inside the session, a few controls do most of the containment work. Specific extensions can be turned off on sensitive apps while staying on elsewhere. Session tokens and cookies can be protected so a malicious update can't simply lift them.

Developer tools, debug mode, and headless mode can stay off by default, since they're common routes for pulling data out of a browser. Copy, paste, download, and screenshot controls then apply to the data itself, regardless of which extensions are present.

Island's Enterprise Browser is one example of this architecture. It evaluates each extension published in the Chrome Web Store, version by version, and alerts administrators when an extension's risk profile changes. Its Extension Guard capability selectively disables extensions when users open sensitive applications.

Island also protects session tokens and cookies with unique encryption, and it keeps developer tools, debug mode, and headless mode off by default under policy. For Chrome, Edge, and other consumer browsers, the Island Extension brings them into the same visibility and policy model.

In practice, a sales rep's favorite email-tracking extension keeps working in webmail and goes quiet when the CRM opens. The rep keeps the tool, and customer records stay out of its reach. The same logic covers AI chat tools in the session, where prompts and responses are exactly the data a harvesting extension wants.

Central management only counts if it covers browsers you don't manage

The extension inventory looks clean on the dashboard, until a contractor signs into the same SaaS tenant from a personal laptop. That laptop runs several unreviewed extensions, and the report doesn't show any of them.

UK NCSC guidance on BYOD notes data protection on personal devices depends on how thoroughly the device can be managed. Meanwhile, the work itself has moved well past the managed fleet.

In April 2025, Gartner described web browsers as "the primary access method for most modern corporate applications." The same release notes enterprise browsers can enable segmented access from unmanaged devices and BYOD.

Managed-device reporting was built for an era when most work stayed on company laptops, and it still does that job well. The gap is everything it wasn't asked to see.

Unmanaged extensions tend to reach corporate data through a few familiar paths:

• Contractor and outsourced-team laptops outside device management
• Personal devices enrolled in BYOD programs
• Personal profiles on a managed browser, where UK NCSC says organizations might limit sign-in to personal sync accounts
• Second browsers installed to get around policy
• Sideloaded or developer-mode extensions, since NCSC treats developer and sideloading functionality as device settings to control

Chasing agents onto each contractor laptop and personal device rarely scales, and it strains the trust BYOD programs depend on. Managing the door works better. Require sensitive apps to be reached through a governed browser or browser layer, enforced with conditional access at the identity provider.

Extension policy then travels with the work, rather than stopping wherever IT happens to have an agent installed. The contractor's personal laptop can still reach the SaaS tenant, but only through a browser where your extension rules apply. Partners don't need an agent on hardware they own, and your policy still reaches the apps you care about.

The device you don't own is often the one with the most interesting extensions.

Extension governance needs an owner, a clock, and a fast yes

An extension request sits in a queue for weeks. Long before anyone answers, the employee has installed it in a personal profile, outside policy and out of view.

Start by naming one owner for extension risk decisions, often a joint IT and security function, and publish a clear path for requests and exceptions. A named owner turns "who decides?" into a service with a response time people can plan around.

The owner doesn't need to review each request personally. Most requests can follow the three-question tiers, so only broad-access or recently changed extensions land on someone's desk.

Speed of approval is a security control, because a slow no or a silent queue produces shadow extensions in personal profiles and second browsers. A fast, scoped yes keeps the extension inside policy: approved for general use and blocked on finance and HR apps. It also shows up in the same inventory as everything else, where you can watch what it does next.

To know whether the program is working, track a short set of metrics:

• Median time from request to decision
• Share of installed extensions with all-sites host access
• Permission-change events re-reviewed within an agreed window
• Extensions disabled on sensitive apps versus removed outright
• Coverage of unmanaged browsers reaching corporate apps

Review these numbers quarterly with IT and security in the same room. When decision time creeps up, shadow installs tend to follow, and the inventory starts drifting from what's running.

Names are easy to list. Behavior is what you govern, and a program built around it lets people keep their favorite tools while your data stays where it belongs.

Your extension policy can follow behavior, not just names

If you're rethinking how your organization manages browser extensions, we're happy to walk through what we've built. Request a demo.

FAQs

How do you manage browser extensions centrally?

Set an allowlist or default-deny baseline in your browser management console, then layer on permission rules, site restrictions, and re-review triggers. Extend the same policy to unmanaged browsers reaching corporate apps so coverage matches real usage.

Are allowlists enough to manage browser extensions?

Allowlists are the right baseline, but they approve an extension's identity at one point in time. Pair them with update monitoring and session-level controls so approval keeps pace with what the extension does.

What should trigger a re-review of an approved extension?

New permissions, broader site access, a change of developer or owner, new remote domains, or removal from the store should each reopen the decision. Treat the updated extension as a new request rather than a routine patch.

How do you control browser extensions on unmanaged or contractor devices?

Require sensitive apps to be reached through a governed browser or browser layer, enforced by conditional access at your identity provider. Extension policy then applies at the point of access instead of depending on device management.

Should enterprises block all browser extensions?

For most organizations, no. Blanket blocking pushes people toward personal browsers, while scoped approval keeps useful extensions visible and restricted on sensitive apps.