Browser Extension Security: The Add-Ons Quietly Reading Your Business Data

The Install Nobody Approved

Your bookkeeper is copying invoice totals out of a customer portal into a spreadsheet, and it is tedious, so she searches the Chrome Web Store for “copy table to spreadsheet.” The third result has four stars and 90,000 users. She clicks Add to Chrome. A gray box says the extension can Read and change all your data on all websites. She clicks Add extension, because that is the only button that makes the box go away and gets her back to work.

That is the entire approval process. No ticket, no review, no record. From that moment a piece of software written by someone neither of you can name runs inside every tab she opens — the accounting portal, the bank, the CRM, the shared inbox, payroll. It sees each page after it renders, meaning it sees the data after decryption, after login, after MFA. Every control you bought sits upstream of it.

Browser extensions are the least-governed software in most small businesses. Nobody approves them, nobody inventories them, nobody notices when one changes hands. This is about governing that whole surface: what the permissions mean, why the risk is the update rather than the install, how to audit what you have, and what a realistic policy looks like when you are 30 people with no security team.

What the “All Websites” Permissions Actually Grant

Extension permissions come in two kinds. API permissions let the extension call browser functions — read bookmarks, manage downloads, watch the clipboard. Host permissions control which websites it can read from and inject code into. Host permissions are the ones that matter, and <all_urls> is the one that should stop you.

For broad host access Chrome shows one sentence: “Read and change all your data on all websites,” or “…on the websites you visit,” depending on scope. That sentence is doing enormous work. It means the extension can read the rendered content of every page (invoice amounts, client lists, message bodies), read and write form fields before submission, read page storage, and usually reach the session cookies and tokens that keep a user signed in. The cookies matter most: a stolen session token can be replayed by an attacker who never learns the password and never trips your MFA prompt — the same mechanic that lets credential stuffing attacks survive a password reset.

Below are the strings a non-technical reader actually sees, using Google’s own warning wording from its extension permissions reference.

What the install box says	Underlying permission	What it actually allows	Risk
Read and change all your data on all websites (or “…on the websites you visit”)	<all_urls> or broad host match	Read and modify every page, including logged-in sessions; typically reach session cookies and tokens	Critical
Access the page debugger backend	debugger	Full DevTools-level control of pages; also carries the all-websites warning	Critical
(shown as all-websites access)	proxy	Redirect or intercept the browser’s traffic	Critical
Communicate with cooperating native applications	nativeMessaging	Talk to a program on the computer, outside the browser sandbox	High
Read data you copy and paste	clipboardRead	See anything copied — including a password pasted out of a vault	High
Read your browsing history	tabs	See the URL and title of every tab, continuously	Medium-High
Manage your apps, extensions, and themes	management	Disable your other extensions, including security ones	Medium
Read and change your bookmarks	bookmarks	Read and rewrite saved links	Low

Several powerful capabilities — storage, scripting, webRequest — produce no install-time warning at all; Chrome folds them into the host-permission line. Even a careful reader gets no itemized list. Treat this as applied least privilege for a small business: the question is never “is this extension trustworthy,” it is “does it need every site, or three sites?”

Manifest V3: What It Fixed and What It Did Not

You will read that Manifest V3 solved extension security. It did not, and the overstatement distorts how businesses think about this.

What MV3 genuinely changed, per Google’s migration documentation: extensions can no longer execute remotely hosted code, closing the trick of shipping a clean bundle to review and pulling a malicious payload afterward. Background pages became service workers. And the blocking webRequest API was replaced for most uses by declarativeNetRequest, where rules are declared up front rather than the extension seeing every request in flight.

What MV3 did not change: content scripts still read and modify page content. That is the core feature of extensions and it is not going away. A malicious MV3 extension with broad host permissions can still scrape everything on screen, harvest tokens, and send them anywhere — it just ships the logic inside the reviewed package instead of fetching it later, and reviewed packages have repeatedly shipped with malicious logic in them. MV3 raised the floor; it did not build a ceiling.

Browser Extension Risk Is the Update, Not the Install

Extensions auto-update silently, and a new owner inherits every permission the old one was granted. Nobody re-consents. Nobody is notified. The extension you vetted in March can be a different program in September, running with the same “all websites” access. Not hypothetical:

• December 2024 — developer account phishing. Attackers emailed extension developers impersonating Google, warning of a Chrome Web Store policy violation. The link led to a malicious OAuth app named “Privacy Policy Extension,” which asked for permission to see, edit, update, and publish the developer’s extensions. Approving it handed over publishing rights. Cyberhaven confirmed its own extension was hijacked this way around December 24–25, 2024; reporting from BleepingComputer and researchers at Sekoia put the campaign at 35 or more compromised extensions with roughly 2.6 million combined users.
• July 2025 — “RedDirection.” Koi Security documented 18 Chrome and Edge extensions with roughly 2.3 million combined users that behaved normally for extended periods, then turned malicious through routine updates. Several carried store verification badges and featured placement at the time.
• December 2025 — “ShadyPanda.” Koi Security reported roughly 145 extensions (about 20 Chrome, 125 Edge) totaling over 4.3 million installs, including widely used new-tab and cleanup tools such as Infinity New Tab and Clean Master. The operators built or bought extensions, ran them cleanly for years to accumulate trust and store badges, then pushed silent updates that turned the browser into a remote-code-execution platform able to log keystrokes and lift authentication tokens. Reporting in January 2026 extended similar sleeper findings to Firefox add-ons.

The pattern is unmistakable: install-time trust signals — star rating, user count, verified badge, “featured” — describe an extension’s past, not its present. This is ordinary third-party and supply chain risk, except the vendor never signed a contract with you and can be sold to a stranger without telling anyone.

How to Audit Every Browser Extension You Have Right Now

Do this on every work machine. Ten minutes per computer, no tooling required.

1. Open the extensions page. Type chrome://extensions in the address bar (or edge://extensions). Do not use the puzzle-piece toolbar icon — it hides unpinned extensions, which is where the problems live.
2. Turn on Developer mode with the toggle in the top right. This exposes each extension’s 32-character ID — that is what goes in your inventory. Publishers can change names; the ID cannot change.
3. Open Details on each one. Record name, ID, publisher, version, and the setting under “This can read and change site data” — on-click only, on specific sites, or on all sites. Anything on all sites goes on a scrutiny list.
4. Check the store listing for each. Look at user count, last-updated date, and whether a real company is named. No identifiable publisher, or no update in two years, is a liability either way — abandoned code is what gets bought.
5. Flag anything no longer in the store. If it is installed but the listing 404s, that is a strong signal it was pulled, often for cause. Remove it and treat that machine’s saved sessions as suspect.
6. Delete everything unused. Not disable — remove. The single highest-yield step in this whole exercise is deleting the six extensions nobody has clicked since 2023.
7. Downgrade what survives. For the keepers, switch site access from “on all sites” to on-click or to the specific sites the tool needs. Most extensions keep working fine.

An Allowlist Policy, and the Version You Will Actually Follow

Two honest options, and the second is not a failure.

The ideal: allowlist by default. Chrome Enterprise Core is free — Google lists it at no cost, and it does not require a Google Workspace subscription. Enroll your browsers, then in the Admin console go to Devices > Chrome > Apps & extensions > Users & browsers and set the allow/block mode. The options are “Allow all apps, admin manages blocklist,” “Block all apps, admin manages allowlist,” and “Block all apps, admin manages allowlist, users may request extensions.” That third one is the small-business sweet spot: employees can still ask, and you approve or deny from the console. Deploying by Group Policy or Intune instead, the policies are ExtensionInstallBlocklist (set to * to block everything by default), ExtensionInstallAllowlist for approved IDs, and ExtensionInstallForcelist to push required tools; ExtensionSettings adds finer control, including blocking by the permissions an extension requests. Microsoft Edge supports the same policy names, documented on Microsoft Learn and deployable through Intune.

The pragmatic version: documented approval plus a quarterly audit. If enrolling browsers is more than you will realistically do this quarter, write three sentences into the handbook — new extensions need approval from the owner or office manager; the approver records name, ID, publisher, and business reason in a shared sheet; the list is re-audited quarterly using the procedure above. Weaker than an allowlist, but it catches the two things that matter: the unapproved install and the abandoned extension that quietly changed hands. A policy you run four times a year beats an allowlist you configure once and never maintain.

Personal Laptops Are the Hard Part

None of this reaches an employee’s own laptop. On an unmanaged device you have no visibility, no ability to block, and no idea whether the machine is also running the kids’ game extensions. Chrome Enterprise Core can enforce policy on a managed work profile signed in with the company account even on a personal device — the most realistic middle ground — but it governs only that profile, and only if the employee uses it. Otherwise fall back to scope reduction: keep the highest-value systems (banking, payroll, the accounting file) off personal devices entirely, the same instinct behind data loss prevention for a small business.

Your Password Manager Is Also a High-Permission Extension

It reads pages, fills forms, and holds every credential you own. Everything above applies to it, and pretending otherwise would be dishonest. The conclusion is not to avoid extensions — it is that when one has that much access, the publisher’s identity, audit history, and incident record are the product. Use a reputable one, keep it updated, do not run two. Choosing which is a separate question: see our comparison of password managers for small business. That post picks a tool; this one governs the whole extension surface around it.

If It Already Happened

If you found an extension pulled from the store, or got a breach notice from a vendor whose extension you run, assume page content and session tokens were exposed. Work in this order:

1. Remove it from every affected machine. Disabling is not enough.
2. Force sign-out everywhere. People skip this and it is the step that matters — a stolen session token works until the session is killed. Google Workspace: Admin console > Directory > Users > the user > Security > Sign out user. Microsoft 365: Entra admin center > Users > the user > Revoke sessions. Same in your banking portal, CRM, and accounting software.
3. Reset passwords for accounts that user touched in the browser — after the sign-out, not before.
4. Check for persistence. Review mailbox forwarding rules and delegates, connected apps and OAuth grants, and MFA methods for anything you did not add.
5. Check the money. Review payment details and ACH/wire recipients in accounting and payroll, and call your bank if anything changed.
6. Write down what happened — dates, extension ID, accounts exposed. Your insurer or a client notification will need it.

What to Do This Week

1. Monday: Run the chrome://extensions audit on your own machine first. Record name, ID, publisher, and site access.
2. Tuesday: Delete every extension you do not actively use; switch the survivors off “on all sites.”
3. Wednesday: Send the procedure to staff, ask for a screenshot of their extensions page, build one shared inventory sheet.
4. Thursday: Check each survivor’s store listing. Remove anything with an unidentifiable publisher, no update in two years, or a dead listing.
5. Friday: Pick a control model — either Chrome Enterprise Core (free) set to “Block all apps, admin manages allowlist, users may request extensions,” or the three-sentence approval rule in the handbook plus a quarterly audit on the calendar. Repeat for Edge if anyone uses it.

For the order of operations on everything else, our first 90 days of cybersecurity for a new business covers the broader sequence — accounts, MFA, backups, devices. Extension governance is one line item there; this article is the deep version of that single line.