Browser extensions run inside the trusted browser session, after MFA has passed, after the VPN check has cleared, and after your EDR has already decided the device is clean. From there, an extension can see almost everything the user sees: email, SaaS dashboards, internal tools, even banking sessions logged in via SSO.
Why extensions slip past every control you've built
Most security stacks are built to stop things from getting in: bad logins, malware, phishing links. An extension doesn't need to break in. An employee installs it voluntarily, usually for a legitimate reason, something like a grammar checker, a PDF tool, or a meeting scheduler. Once installed, it stops being a visitor. It becomes part of the browser, with whatever access it asked for and the user granted.
Your firewall doesn't inspect it. Your EDR generally isn't looking at browser-level data access. Your MFA already did its job letting the user in; it has no opinion on what runs inside that session.
There's also a supply-chain angle: a perfectly reasonable extension can change hands, get acquired, or push an update that quietly adds tracking or data-harvesting code. Because extensions auto-update by default, that change rolls out without anyone re-approving it.
The permission test: a 30-second way to judge any extension
You don't need a security team to start filtering out the obvious risks. Use one heuristic consistently: if an extension can read and change data on every site the user visits, treat its access like you'd treat a shared admin login. Would you hand an employee that level of access just so they could use this one tool? If the answer is no, question why the extension has it.
To check this in a browser like Chrome or Edge: open the extensions page, click "Details" on any extension, and look at "Site access." Anything set to "On all sites" deserves a second look.
Then ask three quick questions:
- Does the job actually require this level of access, or would "on click" or specific sites work just as well?
- Is the publisher a recognizable, established company, or an anonymous developer with a generic name?
- Is there a clear business reason someone can state in one sentence, or is it just convenience?
If an extension fails two of these three, it's a candidate for removal. That doesn't mean it's malicious; it means the risk-to-benefit ratio doesn't hold up.
Audit this week: a lightweight review checklist
You don't need new tooling to get a first pass done. If your team uses Google Workspace or Microsoft 365 with managed Chrome/Edge profiles, you likely already have an admin console that lists every extension installed across the organization. If you don't, a short manual pass still works for smaller teams:
- Inventory: pull the extension list from the admin console, or ask each team to screenshot their browser's extensions page.
- Flag high-risk: mark anything with "on all sites" access or broad permissions like reading browsing history or clipboard content.
- Validate business need: for each flagged item, get a one-line justification from the user or their manager.
- Remove the unexplained: anything nobody can justify in under a minute gets disabled.
- Bake it into the lifecycle: add an extension check to onboarding (what's approved) and offboarding (nothing lingers on a departed employee's old device).
This is a few hours of work, not a project. It closes a gap that's invisible to almost every other control you've paid for.
"We can't just ban extensions, people need them"
Fair objection, and the right answer isn't a blanket ban. Password managers, ad blockers, and scheduling tools are genuinely useful. Banning everything just pushes people to find workarounds on personal devices you can't see at all.
The more durable fix is moving from "block everything" to an allowlist with justification: approve a short list of vetted extensions for common needs, require a quick business reason for anything outside that list, and revisit the list on a regular cadence rather than treating this as a one-time cleanup. Extensions get bought, updated, and repurposed, so a policy that only runs once goes stale fast.
If you don't have central browser management in place yet, start with a shared document: approved tools, who approved them, and when they were last checked. It's not elegant, but it's far better than no record at all, and it gives you something to formalize once you invest in proper device management.
Where this fits into your broader security program
Extensions are one more example of a "modern endpoint" that doesn't look like the endpoints most security programs were designed around. That's part of why ongoing oversight matters more than a one-off check. See our managed security service for how continuous monitoring catches this kind of drift before it becomes an incident.
If you don't have anyone internally whose job it is to set and enforce a policy like this, that's exactly the kind of gap a virtual CISO is built to close: someone senior making these calls as part of a real program, not just a document nobody reads.
For a broader, qualified source on browser and endpoint hardening guidance, CISA's resources are a solid starting point: https://www.cisa.gov
Next step
If you want a second pair of eyes on where your biggest blind spots actually are, extensions included, start with our free security review. No pressure, just a clear picture of what's exposed and what to fix first.
