Browser extension permissions tell you what's possible, not what's happening.

When a security team evaluates a browser extension, the easy default is to read the manifest. What permissions does it declare? Which sites can it touch? Check the boxes, make a call, move on.

‍

Extensions are part of the Workforce Edge: the tools, accounts, and apps employees pull in on their own to get work done. Permission review is where that gap between what's allowed and what's actually happening becomes concrete.

‍

The problem is that the permission model gives you very little to work with. There are scoping mechanisms, to be fair. Manifest V3 lets developers declare host permissions against URL match patterns, request permissions at runtime instead of install time, and use activeTab to limit access to the tab a user is actively clicking on. But the ceiling of granularity is the domain. You can scope an extension to mail.google.com, but you can't scope it to "read the compose window and nothing else." Within any site it can reach, an extension can read page contents or it can't. It can inspect web requests or it can't. There's nothing in between.

‍

And in practice, even domain-level scoping rarely happens, because of how extensions create value. Most extensions exist precisely because they work across applications. A grammar checker, a password manager, a screen recorder, a coupon finder: the whole value proposition is that it follows you everywhere, which means it needs access everywhere. The extensions that do target a single application tend to target the applications where your most sensitive data lives. Nobody builds an extension for a niche internal tool. They build extensions for Gmail, for Salesforce, for your CRM. So the "narrow" grant is full access to your email, which is not a meaningfully smaller blast radius.

‍

The result is that broad permissions are the norm, not a red flag. "Reads all page content on all sites" stops looking alarming and starts looking standard. And a permission being standard doesn't make it benign. The declared permission tells you what an extension can do. It tells you nothing about what it does.

‍

The one advantage we have

Here's what makes browser extensions different from most third-party risk problems: we have the source code.

‍

Compare this to OAuth grants. When an employee authorizes a third-party app against your Google Workspace or Microsoft 365 tenant, you can see the scopes it requested. That's it. The app's actual behavior happens on someone else's infrastructure, entirely out of view. You're making a trust decision based on a label the vendor wrote for themselves.

‍

Browser extensions flip that. The JavaScript is delivered to every machine that installs it. You can read what the extension actually does with the access it was granted. You can check whether an extension that claims to fix your grammar is also shipping page contents to an analytics endpoint, or whether a coupon finder is scraping every form you fill out. You can match declared purpose against actual behavior, which is exactly the analysis you wish you could do for every OAuth grant and never can.

‍

That's a real advantage. It's also a real burden, because now the analysis is possible, and "possible" has a way of becoming "expected."

‍

Why the standard playbook falls short

Most organizations that try to get ahead of this reach for managed browser controls, typically allowlisting extensions through Google Workspace or Chrome Enterprise. It's a reasonable instinct with two severe limitations.

‍

First, it only applies to corporate-managed profiles. An employee signed into a personal Chrome profile on the same laptop is outside the policy entirely, and users can still sideload extensions in plenty of configurations. Second, it only covers Chrome. Edge, Firefox, Brave, Arc, and whatever browser ships next are completely invisible to it. Most organizations struggle to run a functioning allowlist for their one officially approved browser. For every other browser in the environment, they're not even struggling. They're blind.

‍

Then there's the review problem itself. Even for the extensions you can see, reading the source of each one, tracking updates (extensions auto-update, and a benign version 2.1 says nothing about version 2.2), and keeping an allow/deny list current is infeasible to do manually at scale. Standing up a team for this is a nonstarter for all but the largest security organizations.

‍

So most teams end up back where they started: skimming manifests, checking install counts and star ratings, and hoping. Which is understandable, but it's worth being honest that this is risk acceptance dressed up as risk assessment.

‍

What good looks like

Two things have to be true to actually manage this risk.

‍

You need cross-browser visibility. Not "the Chrome profiles we manage," but every extension in every browser your employees actually use. If your inventory has a browser-shaped hole in it, that hole is where the problem lives.

‍

And you need the analysis and the response to be automated, because no team can read this much JavaScript. This is exactly what we built our new agentic browser extension analysis at Nudge Security to do. It discovers extensions across browsers, analyzes actual behavior against declared purpose and permissions, and then goes a step further: it automates the mitigation and remediation actions too, so a risky finding turns into a resolved one without a human queue in the middle.

‍

The source code is right there. Now something is actually reading it.

‍

See how it works →