What Are Browser Extension Risks? Permissions and Defense

A grammar checker your sales team installed two years ago is reading every page they open. Not the marketing copy, every page: the CRM, the cloud console, the webmail, the internal wiki behind SSO. It declared one permission at install, "Read and change all your data on websites you visit," the user clicked through, and nobody looked again. The extension does its job. It also has a standing capability to scrape any field, read any session cookie, and quietly post what it sees to a server you have never heard of. Whether it ever does is up to whoever controls the code, and that owner can change without warning.

That is the problem with browser extensions as a security topic. The risk is not that they are exotic malware. The risk is that legitimate, useful extensions hold extraordinary access to everything a user does in the browser, that access is granted once and rarely reviewed, and the code behind it can be sold, compromised, or updated into something hostile after you trusted it. This guide covers what extensions are and the permission model that makes them dangerous, the four ways a trusted extension turns malicious, what that access actually enables, where this sits in MITRE ATT&CK, and how a defender inventories, restricts, and detects them.

What browser extensions are and why they are an attack surface

A browser extension is a small program that runs inside the browser and changes how pages behave: an ad blocker, a password manager, a screen recorder, a grammar checker, a coupon finder. It is built from the same web technologies as the pages it modifies, packaged, and installed from a store like the Chrome Web Store or loaded directly. Once installed, it runs with whatever permissions the user approved, on its own schedule, including in the background.

That last part is what makes extensions an attack surface rather than just software. An extension is code you did not write, running inside the one application that touches every web app your organization uses, with access scoped by a permission prompt most users do not read. The browser is where work happens now: email, finance, cloud administration, source control, customer data. An extension granted broad access sits behind all of it, on the authenticated side of every login, with no further checks once the user is signed in.

Two properties make the surface worse than ordinary installed software. First, the permission model is coarse and the dangerous tier is common. Second, the code can change underneath you through auto-update, and the identity behind the code can change through a sale or a compromise. A defender has to treat an installed extension not as a fixed thing but as a standing trust relationship with a party who may not be the same party tomorrow.

The permission model: host permissions and "all your data"

Extensions declare the permissions they need in a manifest, and the browser surfaces the riskiest ones to the user at install time. The category that matters most is host permissions: the set of sites an extension is allowed to read and modify. An extension that requests access to all sites triggers the warning every analyst should recognize: "Read and change all your data on websites you visit." Chrome shows it because the grant is exactly that broad. With it, the extension can read the content of every page the user loads, change that content, and watch the requests the browser makes.

Concretely, broad host permissions plus the matching APIs let an extension read sensitive tab properties like the URL and title, inject scripts into pages, read and set cookies through the chrome.cookies API, and observe network requests. None of that requires a fresh prompt at use time. The user consents once, at install, and the capability is standing from then on. There is no "this extension is now reading your bank session" notification.

The trouble is that the broad grant is not rare or suspicious on its own. Many legitimate extensions genuinely need wide access to function: a password manager has to read login forms on every site, a screen recorder has to see the page, a web-clipper has to read content anywhere. Industry analysis of installed extensions has repeatedly found that well over half request permissions that could be considered excessive for what they do. So the host-permission warning cannot be used as a clean malicious-or-not signal. The defender's problem is that the most dangerous permission is also one of the most common, which means consent fatigue is built into the model: users approve "all your data" so often that the prompt stops meaning anything.

Chrome lets a user narrow a granted extension after install, switching "on all sites" to "on specific sites" or "on click." Almost nobody does. Access granted at install tends to persist for the life of the extension, which is the gap an attacker plans around.

How a trusted extension turns malicious

An extension does not have to be malicious when you install it. The more common and more dangerous path is that a trusted extension becomes malicious later. There are four routes.

Malicious from the start. The extension is built to steal and disguised as something useful, a free VPN, a PDF converter, a theme. It passes store review because static review of extension behavior is limited, then does what it was built to do once installed. MITRE notes plainly that store security mechanisms may be insufficient to detect malicious components.

Sold or transferred, then updated. An extension gains a real user base, the original developer sells it, and the new owner pushes an update that adds tracking, ad injection, or data theft. The users never re-consent. They installed a tool from a developer they trusted; the trust transferred to a stranger through the auto-update channel without anyone clicking anything.

Developer account compromised. The most consequential route in practice. An attacker phishes the developer's store credentials and publishes a malicious version under the legitimate developer's name. It auto-updates to the existing install base in hours. This is a software supply chain attack: you are not breached through a vulnerability in your environment, you are breached through a trusted vendor whose pipeline was the actual target.

The Cyberhaven incident is the worked example. On December 24, 2024, a Cyberhaven employee received a phishing email and was walked through Google's real OAuth consent screen to authorize a malicious application named "Privacy Policy Extension." That consent granted the attacker the ability to publish to the Chrome Web Store. The attacker uploaded a malicious version of Cyberhaven's extension, version 24.10.4, which then auto-updated to roughly 400,000 users. The malicious code exfiltrated authenticated sessions and cookies, with Facebook Ads accounts as a primary target. Cyberhaven detected and pulled it within about a day, but public reporting tied it to a wider campaign that compromised more than 30 other Chrome extensions affecting over 2.6 million users. Note the mechanism: no malware ran on any endpoint, no firewall rule was crossed. A trusted extension updated itself, exactly as designed.

Consent (OAuth) abuse. Cyberhaven's initial compromise was itself an OAuth-consent phish: the developer was not tricked out of a password, they were tricked into granting a malicious app real, durable permissions through a legitimate authorization flow. The same pattern targets ordinary users, where a "sign in to continue" prompt grants a rogue app standing access to mailbox or drive data. It is the extension problem in another shape: a one-time consent that hands over lasting access.

What malicious extensions enable

Once an extension has broad access and hostile code, the capabilities follow directly from where it sits. It is inside the browser, on the authenticated side of every session.

Credential and session theft. The extension reads what the user types into login forms and lifts session cookies and tokens directly. Stolen session cookies are worse than stolen passwords: they let an attacker resume an already-authenticated session and walk straight past MFA, because the second factor was already satisfied when the session was created. This is the same outcome as credential dumping on an endpoint, reached without touching the endpoint, from inside the browser where the secrets are already decrypted and in use.

Traffic injection and manipulation. With the ability to change page content, an extension can inject ads, rewrite links, swap a displayed wallet address, insert a fake login overlay, or alter what the user sees a transaction to be. The page looks normal because the modification happens in the browser after the legitimate page loads.

Surveillance and exfiltration. Background page access means the extension can read the URLs, titles, and content of everything the user browses and report it out. For a targeted user, that is a near-complete record of their work: which systems they use, which customers they look at, what is in the internal apps that never leave the browser.

Command and control and persistence. Malicious extensions can phone home for instructions and pull new payloads, turning the browser into a node the attacker controls. Because the extension reinstalls itself across browser restarts and rides the sync profile, it is also a quiet way to keep a foothold.

MITRE ATT&CK: T1176.001 Browser Extensions

ATT&CK tracks this directly. The parent technique is T1176 Software Extensions, and the relevant sub-technique is T1176.001 Browser Extensions, mapped to the Persistence tactic (TA0003). That tactic placement is the useful part for a defender: ATT&CK classifies a malicious browser extension primarily as a way for an adversary to keep access, not as a one-off theft.

The technique description matches what the incidents show. Extensions can browse to sites in the background and steal everything a user enters into the browser, including credentials. They can be installed through deceptive store downloads, social engineering, or by an attacker who already has access modifying browser configuration files to load an extension silently. The documented uses span credential theft, ad injection, botnet command and control, and stealthy browser manipulation. Mapping a detection or an incident to T1176.001 keeps the framing right: the extension is persistence, and the data theft is what that persistence is used for.

Detection and management for defenders

Extensions are hard to catch with endpoint tooling because they do not behave like programs. Installing one does not spawn a process or write a recognizable binary; it drops files inside the browser profile and runs inside the browser's own process. There is no process-start event to alert on. That is precisely why management has to be proactive rather than detective. The controls below are roughly in order of leverage.

Enforce an allowlist or blocklist by policy. Both Chrome and Edge expose enterprise policies (ExtensionInstallAllowlist, ExtensionInstallBlocklist, ExtensionInstallForcelist) that control which extensions can install. Setting the blocklist to * and then allowlisting only approved extension IDs is the single highest-leverage control: it changes the model from "any extension a user finds" to "only what we vetted." This is the browser equivalent of application allowlisting, and it is the one step that actually shrinks the surface instead of just watching it.

Maintain an extension inventory. You cannot govern what you cannot see. Pull the installed-extension list across the fleet, by extension ID and version, from browser management (Chrome Browser Cloud Management, Edge management, or an endpoint tool that reads the profile). The inventory is what turns "did anyone have the Cyberhaven extension at version 24.10.4" from a guess into a query, and it is the prerequisite for everything else.

Review the permissions, not just the names. For every approved extension, look at the host permissions and APIs it requests. An extension that asks for all-sites access, cookie access, and webRequest is a different risk class from one scoped to a single domain. Treat broad host permissions and cookie access as the items that need a justification, and re-review on major version bumps, because a sold or compromised extension expresses itself as a permission or behavior change in an update.

Understand what Manifest V3 changes, and what it does not. Chrome's Manifest V3 is the current extension platform; Manifest V2 extensions have been disabled in stable Chrome since the October 2024 rollout. The most-cited security change is that the blocking webRequest API, which let an extension inspect and modify every network request in real time, was replaced by declarativeNetRequest, where the extension submits static rules and Chrome's engine does the matching. That removes one powerful interception primitive from arbitrary extensions. It does not solve the core problem. An extension with broad host permissions can still read page content, read and exfiltrate cookies, and inject scripts. And the blocking webRequest capability remains available to extensions force-installed in managed environments by enterprise policy. Manifest V3 narrows one technique; it does not retire the attack surface.

Treat extensions as a persistence and incident vector. Because ATT&CK files this under persistence, fold it into incident response. When an account is compromised, the installed-extension list and the browser sync profile are part of the scope, not an afterthought, because an attacker who can install or ride an extension keeps access through password resets and reimages of other footholds. Watch browser traffic to extension-update and unknown endpoints, and alert on new extension installs outside the allowlist where management telemetry supports it.

Browser extension risk tiers

Not every extension is the same risk. The tier is driven by the permissions granted and the trust placed in the code over time, not by what the extension claims to do.

The point of the table is the second column. A defender ranks an extension by what it can touch, not by its category in the store. A "grammar checker" with all-sites access is a high-risk standing capability regardless of how benign its function sounds, because the function is not the threat. The access is.

The bottom line

Browser extensions are dangerous not because they are unusual but because they are trusted, broadly permissioned, and rarely revisited. An extension granted "all your data on websites you visit" sits on the authenticated side of every session your users open, and the code behind it can be sold, phished, or auto-updated into something hostile without anyone re-consenting. Cyberhaven showed the full chain: a single OAuth-consent phish turned a trusted security tool into a session-stealer for 400,000 users overnight, as one extension in a campaign that hit millions.

For a defender the work is unglamorous and effective. Allowlist by policy so only vetted extensions install. Inventory what is deployed by ID and version so you can answer "who has this" in seconds. Rank extensions by the access they hold, not the function they advertise, and re-check that access on every update. Treat the installed-extension list as persistence, because ATT&CK does, and fold it into incident scope. Manifest V3 helps at the margin; the access model is the surface, and the access model is still wide open.