What Is a Browser Extension? The Permissions Your Users Just Granted

Updated: October 2026

A user installs a coupon finder, a PDF tool, or an AI helper, clicks Add to Chrome, and nobody on your side hears about it. That one click often hands a stranger's code the right to read every page the user opens, including the client's bank portal and your own RMM console. This guide explains what a browser extension is, what the permission prompt grants, how trusted extensions turn hostile, and how to put the install decision back in your hands with policy.

What a Browser Extension Is

A browser extension is a small program that runs inside the browser and changes how it behaves. It can add a button, rewrite a page, block ads, fill passwords, or watch every request the browser makes. Chrome, Edge, Firefox and Safari all support them, and Chrome and Edge share the same format, so one package usually runs in both.

Under the hood an extension is a zip of web files: a manifest that declares what it wants, scripts the browser injects into web pages (content scripts), and a background service worker that runs when needed. It ships through a store, Google's Chrome Web Store or Microsoft's Edge Add-ons, and the browser updates it automatically in the background. That last part matters more than it sounds. The user approves an extension once, and from then on every new version lands without a second look.

The reason extensions sit in a different risk class from ordinary apps is where they run. They live inside the one program that holds the user's logged-in sessions to Microsoft 365, the bank, the PSA and the password manager. An extension with broad permissions sees what the user sees, after the login, after MFA, in plain text.

The Permission Model, in Plain Words

Extensions ask for two kinds of access. API permissions turn on browser features: tabs, history, cookies, downloads, clipboard. Host permissions say which sites the extension may touch, written as patterns like https://*.example.com/*. The broadest pattern, <all_urls>, means every site, and it produces the warning Chrome's permissions reference phrases as "Read and change all your data on all websites."

That sentence is doing a lot of work. "Read" covers page content, form fields and anything the user types. "Change" covers injecting scripts, rewriting links and replacing a login form with a copy. "All websites" includes internal tools, webmail and the admin console of every SaaS the client pays for. Users click through it because the dialog looks like every other dialog.

Two details help on the defensive side. Chrome shows the warning at install time, and if an update adds a permission that triggers a new warning, the extension is disabled until the user accepts it. And users can shrink an extension's site access after install from the extension's details page: on click only, on specific sites, or on all sites. A clipboard tool does not need the bank.

Not every permission is scary. activeTab grants temporary access to the current page only when the user clicks the extension's icon, and it shows no warning at all. When two extensions do the same job and one asks for activeTab while the other asks for all sites, the choice is easy.

Manifest V3: What Changed and What Did Not

Manifest V3 is the current extension format for Chrome and Edge. It closed three doors that older extensions used. Extensions can no longer load code from a remote server at runtime, so everything they run has to be in the package the store reviewed. Persistent background pages became service workers that only run when needed. And the blocking form of the webRequest API, which let an extension sit in the path of every request, was replaced by a declarative rule system.

Chrome's deprecation timeline finished the job in stages. V2 extensions were disabled by default on March 31, 2025. The user-side re-enable switch went away with Chrome 138 on July 24, 2025, and the enterprise override policy went with Chrome 139. On August 31, 2026 the remaining V2 extensions were removed from the Chrome Web Store, so a fleet still on Chrome 138 to keep an old extension alive is a fleet that stopped getting security updates a year ago.

What V3 did not change is the trust model. A reviewed package can still request all sites. A legitimate developer account can still be phished. And auto-update still delivers whatever that account publishes next. The incidents below all happened under V3 rules.

How Trusted Extensions Turn Malicious

The pattern that keeps repeating starts with a good extension that changes owners, or changes its mind, after it has already been approved on thousands of machines.

The clearest case is Cyberhaven, a security vendor whose own Chrome extension was hijacked over Christmas 2024. Per BleepingComputer, an attacker phished an employee with Chrome Web Store admin rights using a fake "policy violation" notice, got the employee to approve a rogue OAuth app, and used that access to publish version 24.10.4 with code that shipped session cookies to an attacker domain. MFA was on and the password was never stolen; the OAuth grant was enough. Follow-up reporting found the same code injected into at least 35 extensions used by roughly 2.6 million people. The same OAuth trick shows up in credential harvesting campaigns against ordinary users, so a developer account is simply a higher-value target.

The slower version is the long con. In December 2025 Koi Security described a campaign it named ShadyPanda, covered by BleepingComputer: 145 Chrome and Edge extensions with about 4.3 million installs combined, several of them carrying Google's Featured and Verified badges, that behaved for years before an update added a backdoor polling a server every hour for JavaScript to run. The badge was earned when the extension was clean. The update arrived after.

Both stories end the same way for the people on your side of the ticket. Nobody installed anything new. The browser updated itself overnight, which is what it is supposed to do, and the first visible symptom was an account doing things its owner did not do. That is also why "it's the same extension we've always used" is not a defense, and why extension spyware deserves the same treatment as any other spyware on a device.

The community has a word for the moment the changelog says "minor bug fixes" and the permissions say otherwise.

Control Extensions With Policy, Not Memos

Telling users to be careful does not survive the first coupon popup. Chrome and Edge both read extension rules from policy, which means Group Policy, Intune, Chrome Browser Cloud Management or a registry key set by your RMM, and the rules are the same in both browsers.

The blunt tool is two lists. ExtensionInstallBlocklist with a single * entry blocks everything, and ExtensionInstallAllowlist names the extension IDs that are exempt. On Windows the Chrome keys live under SOFTWARE\Policies\Google\Chrome and the Edge keys under SOFTWARE\Policies\Microsoft\Edge, same names, per Microsoft's Edge policy reference. An extension that is already installed and lands on the blocklist gets disabled, so audit what users have before you flip the switch, or the first morning after rollout is a wall of tickets.

The precise tool is ExtensionSettings, one JSON policy that replaces both lists. A * entry sets the default for every extension, usually "installation_mode": "blocked" with a blocked_install_message that tells the user who to ask. Named entries then set allowed, force_installed or removed per extension ID. Two fields do the work the lists cannot: blocked_permissions refuses any extension that asks for, say, history or nativeMessaging, even if it is allowed, and runtime_blocked_hosts keeps every extension off named sites, so the client's banking portal and your own tools are out of reach no matter what gets installed. The Group Policy Editor is the quickest way to test the policy on one machine before it goes into a GPO.

Google's admin console offers the same thing as three modes: allow all with a blocklist, block all with an allowlist, or block all and let users request an extension you then approve. The request mode is the one that keeps the help desk out of it. The user asks from inside the browser, you approve the ID once, and it rolls out.

For a one-machine walkthrough of the block-all-then-allow setup in the local policy editor, this one covers it start to finish.

Where to Start

Start with an inventory, because every policy decision depends on knowing what is installed today. Chrome keeps each profile's extensions under the user's AppData\Local\Google\Chrome\User Data\Default\Extensions folder and Edge under the matching Microsoft path, so a script that lists those folders and reads each manifest's name, version and permissions gives you the fleet view in one run. If you run OpenFrame, that inventory is one script run across a client's devices with the output collected in one place. Most of what you find will be harmless, and the few that ask for all sites are your shortlist.

Then pick the mode. Block-all with requests is the right default for a managed client; allow-all with a blocklist is the fallback for a client who will not accept the friction. Either way, add runtime_blocked_hosts for the sites that matter most and blocked_permissions for the ones no business extension needs. Re-check the inventory monthly, because the extension that was clean at the audit is the one that updates.

An extension is a program with the keys to the browser, delivered by a store, updated by a stranger. Treat it like software you deploy, not a setting the user picked. If you are already chasing Chrome for other reasons, our guides on Chrome memory usage and the firewall prompt behind allow Chrome to access the network cover the two tickets that usually arrive next.