The short version

  • A browser extension is third-party software running inside one of the most sensitive applications on your computer, and some extensions legitimately require access to the pages you visit.
  • A permission such as “read and change” site data describes capability, not guilt: a trustworthy extension may need it, but the same access becomes dangerous if the extension is malicious, vulnerable or later compromised.
  • Extensions can become risky after installation because browsers routinely update them, turning the developer account and update pipeline into part of the security boundary.
  • Store review and newer extension platforms reduce risk but do not eliminate it. The practical defence is fewer extensions, narrower permissions and periodic audits of what remains installed.

The extension is software, not a decoration

Browser extensions feel smaller than normal applications because their interface is often tiny: an icon, a popup, a right-click command.

Their position in the system is much bigger.

An extension runs inside the browser — the same place where people open email, bank accounts, work dashboards, social networks, cloud storage and admin panels. To do useful things there, extensions can request powers that ordinary websites do not have.

That is the bargain.

An ad blocker needs to interact with pages and network requests. A password manager may need to recognize login forms. A grammar tool has to see text if it is going to correct it. A shopping extension may need to know which product page is open.

Those are legitimate reasons for access.

They also explain why a browser extension can become a serious security problem without ever looking like traditional malware.

Permissions define the blast radius

When Chrome warns that an extension can “read and change” data on websites, the wording is not theatrical. Google’s Chrome Web Store permission guide says access to data on all websites can allow an extension to read, request or modify data from every page you visit.

That does not mean an extension requesting broad access is malicious.

It means the extension has been given a broad capability.

That distinction matters. Permissions are closer to a map of what software could do than a record of what it has done.

A password manager and a credential-stealing extension may both need to interact with a login page. Their intentions are radically different; the browser cannot infer those intentions from the permission alone.

The same problem appears with less dramatic extensions. A tool that changes the appearance of a website may need access to that site’s page content. If it asks for access to every site instead, the consequence of a bug or compromise becomes much larger.

This is why “least privilege” matters outside enterprise security jargon: an extension should have no more access than its feature actually needs.

Chrome gives users some control after installation. In Chrome’s extension-management settings, compatible extensions can be limited to access when selected, on specific sites or on all sites. Firefox likewise exposes extension permissions and encourages users to compare requested access with the feature being offered.

The best permission is the one an extension never receives.

There are four different ways an extension can go bad

The obvious case is a malicious extension built to steal data from day one.

It is not the only case, and arguably not the most interesting one.

1. It was malicious from the start

A developer can disguise surveillance, credential theft, advertising abuse or redirection behind a useful feature.

Browser stores try to detect this. Chrome has review systems and developer policies. Mozilla scans submitted extensions and subjects some to human review.

But store presence is not proof of perfect safety. Mozilla’s own extension-safety guidance explicitly says review cannot guarantee that an extension is absolutely safe.

The useful question is not “is it in the store?”

It is “who made it, what does it need, and does that access make sense?”

2. It is legitimate, but vulnerable

An extension can have honest developers and still contain a security flaw.

That matters because extension code sits between websites and privileged browser capabilities. A vulnerability can sometimes let a malicious webpage abuse the extension as a bridge to something the webpage could not normally reach.

Researchers have repeatedly demonstrated this class of problem. A 2023 USENIX Security study found 59 vulnerabilities across 40 extensions in its analysis, including flaws that could support privilege escalation and theft of sensitive data.

The lesson is familiar from every other software category: benign code can still be exploitable code.

3. It collects more than the user realizes

Not every privacy problem requires an attacker.

Some extensions are simply built around access to browsing data, page content or user interaction that people may not realize they are sharing.

A 2024 USENIX Security paper tested modern Chrome extensions against sensitive sites including Gmail, Outlook, PayPal and social platforms. The researchers reported privacy risks across thousands of extensions and found hundreds automatically extracting user content from webpages.

Again, access is not automatically abuse. Some extensions need page content to provide the feature the user asked for.

The risk is that a browser page can contain much more than the small fragment an extension appears to need.

4. A trusted extension changes later

This is the one that breaks the simple “I checked it before installing” model.

Chrome is designed to automatically update installed extensions, checking for newer versions on startup and periodically afterwards. Automatic updates are important because they deliver bug fixes and security patches.

They also mean the code you approved on installation day is not necessarily the exact code running six months later.

That makes the extension’s developer account, build process and publishing access part of your security boundary.

If any of those are compromised, an attacker may not need to convince users to install a suspicious new extension. The attacker can try to turn an already trusted one into the delivery channel.

The Cyberhaven incident showed the supply-chain problem clearly

In December 2024, attackers compromised publishing access for Cyberhaven’s Chrome extension and pushed a malicious version through the normal extension-distribution channel.

The Cyber Security Agency of Singapore warned that Cyberhaven was part of a wider campaign affecting Chrome extensions. The malicious code could exfiltrate authenticated sessions and cookies, potentially allowing attackers to impersonate victims without first obtaining the username and password.

That is an important detail.

People often imagine credential theft as a fake login page capturing a password. A compromised extension can be positioned after login, inside the browser session that has already been authenticated.

That does not make passwords or passkeys useless. It means authentication and session security are different layers. A strong login method can prevent one class of account takeover while malicious code already running in the browser attacks another.

The Cyberhaven case is useful because the extension did not need to earn every affected user’s trust from zero on the day of the attack. The legitimate extension had already done that.

The update path carried the new risk.

Manifest V3 closes one door, not every door

Chrome’s move to Manifest V3 changed the extension security model in several important ways.

One of the clearest is the ban on remotely hosted extension code. Google’s Manifest V3 documentation explains that executable JavaScript is expected to be included in the extension package rather than pulled from an outside server after review.

That removes a dangerous pattern: submitting one version for review and then quietly fetching different executable code later.

It does not make extensions harmless.

An extension can still be over-permissioned. It can still contain a vulnerability. A developer account can still be compromised and a malicious packaged update can still be submitted. An extension can still send data to a remote service when that behaviour is part of its permitted design and policy-compliant functionality.

Platform hardening changes the attack surface. It does not erase the need to trust third-party code.

Reviews and install counts are weak shortcuts

A large install count is reassuring in one narrow sense: other people have used the extension.

It is not a security audit.

The same is true of star ratings. Reviews can help reveal broken behaviour, unwanted advertising or suspicious changes, but ordinary users are unlikely to detect quiet data collection or a supply-chain compromise from the toolbar.

A better assessment combines several signals:

QuestionWhat you are actually checking
Who publishes it?Whether the developer or organization is identifiable and consistent with the product.
What permissions does it request?The maximum access the extension is asking you to trust it with.
Do those permissions match the feature?Whether a narrow utility is asking for strangely broad control.
Does it explain data collection?Whether the privacy model is visible before you grant access.
Is it actively maintained?Whether security fixes and browser changes are likely to be addressed.
Has something changed recently?Whether ownership, permissions, behaviour or update history deserves another look.

None of these proves safety by itself.

Together, they are better than “it has 200,000 users, so it must be fine.”

A five-minute extension audit is worth doing

The safest extension is not necessarily the one with the fewest permissions. Some genuinely useful tools need broad access.

The cleaner rule is: keep only the extensions whose value justifies their access.

Start by opening your browser’s extension manager and removing anything you no longer use. Google’s own account-security guidance recommends removing browser extensions that are unnecessary or untrusted.

Then inspect what remains.

Pay particular attention to extensions that can read and change data across all sites. If Chrome lets you narrow that access to specific sites or to the moment you select the extension, do it unless the feature genuinely needs continuous access.

Check whether the developer still looks like the same developer you intended to trust. Read the current store description and privacy disclosures. If an extension suddenly wants a new permission that does not fit its purpose, treat that as a reason to investigate rather than another dialog to dismiss.

Chrome’s Safety Check can also warn about potentially harmful extensions. Firefox users can inspect permissions from the Add-ons Manager, and Mozilla’s Recommended Extensions program applies a higher level of ongoing review to a curated subset of add-ons.

For especially sensitive browser work — financial accounts, administrator consoles, crypto wallets or corporate systems — reducing the number of installed extensions reduces the number of third-party components sitting inside those sessions.

That is not paranoia. It is attack-surface management.

The useful mental model

A browser extension is a small application with a potentially privileged seat inside your browser.

Its security depends on more than whether it looked trustworthy when you installed it.

It depends on what access you granted, what code it runs, how well that code is written, who controls its updates and whether you still need it.

That is how browser extensions become security risks.

Sometimes the extension was bad all along.

Sometimes it was merely too powerful.

And sometimes the dangerous version arrives long after you stopped thinking about the extension at all.

Sources & reference material

  1. Permissions requested by apps and extensionsGoogle Chrome Web Store Help · Accessed Oct 10, 2026

    Explains Chrome extension permission warnings and the access implied by broad permissions, including the ability to read or modify data on websites.

  2. Install and manage extensionsGoogle Chrome Help · Accessed Oct 10, 2026

    Documents Chrome controls for limiting an extension's site access to selected use, specific sites or all sites.

  3. The Chrome Extension update lifecycleChrome for Developers · Accessed Oct 10, 2026

    Documents Chrome's standard automatic extension-update process and periodic update checks.

  4. Extensions / Manifest V3Chrome for Developers · Accessed Oct 10, 2026

    Explains Manifest V3 security changes, including the removal of remotely hosted extension code.

  5. Tips for assessing the safety of an extensionMozilla Support · Accessed Oct 10, 2026

    Explains how Firefox users can assess extension developers, permissions, privacy policies and review status, while noting that review cannot guarantee absolute safety.

  6. Arcanum: Detecting and Evaluating the Privacy Risks of Browser Extensions on Web Pages and Web ContentUSENIX Association · Accessed Oct 10, 2026

    Research showing that extensions with sufficient access can expose sensitive page content and documenting automated extraction of user content by hundreds of extensions.

  7. Extending a Hand to Attackers: Browser Privilege Escalation Attacks via ExtensionsUSENIX Association · Accessed Oct 10, 2026

    Research demonstrating that benign but vulnerable extensions can create security problems, including privilege-escalation paths and theft of sensitive data.

  8. Ongoing Campaign Targeting Chrome Browser ExtensionsCyber Security Agency of Singapore · Accessed Oct 10, 2026

    Government advisory on the 2024 campaign that compromised legitimate Chrome extensions and could exfiltrate authenticated sessions and cookies.