How to Vet a Browser Extension
A browser extension runs inside the same browser you use for banking, email and work — often with permission to read and change everything you see. That makes extensions a quiet but serious supply-chain exposure. This guide shows how to judge one before you install it, and how a team can keep a managed fleet to a small, vetted set.
In plain words
Vetting a browser extension means checking whether it asks for more power than its job needs before you trust it with your browser — and PlayCISO has a free, browser-based extension scanner that surfaces those signals for you. Compare requested permissions against actual function, scrutinise host access, watch for obfuscated or remote-loaded code, and check who owns it now.
The core principle is least privilege: a legitimate extension asks only for what it needs, and the broader the access, the more a future silent update can quietly do.
Step by step
- 1
Read the permissions and ask "why this one?"
Open the listing and the manifest and read every requested permission. For each one, ask whether the extension's stated job actually needs it — a theme does not need to read and change your data on every site, and a note-taker does not need tabs, webRequest or clipboard access. Permissions like "read and change all your data on websites you visit", scripting and management are the high-impact ones; an unexplained request for them is the single strongest reason to walk away.
- 2
Scrutinise host access
Host permissions decide which sites the extension can read and inject into. "<all_urls>" or "*://*/*" means it can touch your bank, your webmail and your admin consoles — a huge blast radius. Prefer extensions scoped to the specific sites they serve, or that use activeTab and optional host permissions so access is granted per use rather than blanket and permanent.
- 3
Look for obfuscated or minified-beyond-reason code
Legitimate extensions ship minified code, but deliberately obfuscated logic — packed strings, eval of remote payloads, code fetched and executed at runtime from a third-party server — is a red flag because it hides what the extension really does and lets behaviour change after review. If the bundle pulls and runs remote scripts, you cannot trust the version you audited to be the version that runs tomorrow.
- 4
Check ownership and listing history
A trustworthy extension can quietly change hands. Established extensions get bought and the new owner pushes an update that adds tracking, injects affiliate links or exfiltrates data — all without reinstalling, because the auto-update inherits the permissions you already granted. Check the publisher, the developer's other extensions, recent reviews mentioning sudden ad or behaviour changes, and whether the developer domain and contact still match the original project.
- 5
Weigh the auto-update risk
Extensions update silently and the update runs with the permissions you already approved, so vetting the current version is necessary but not sufficient. The broader the permissions, the more a future malicious or compromised update can do without asking again. Favour narrowly-scoped extensions, keep the installed set small, and periodically re-review the permissions of ones that update frequently or that you no longer use.
- 6
Prefer official stores and verified publishers
Install from the official web store rather than a sideloaded CRX or a random download, and prefer listings with a verified or featured publisher badge, a real support site and a privacy policy that names what data leaves the browser. Side-loaded extensions bypass store review entirely. None of these signals is proof on its own, but together they raise the bar an attacker has to clear.
- 7
Enterprise: allow-list instead of block-list
For a managed fleet, default to blocking all extensions and allow-list only the vetted ones by ID via browser enterprise policy (ExtensionInstallAllowlist / ForceInstall). Pin to the specific extensions and, where possible, control updates so a silent push does not change what is deployed under you. Pair the policy with a periodic re-review of the allow-list, since an approved extension can change ownership or behaviour after it was first cleared.
Point the browser-based scanner at an extension to surface its requested permissions, host access and risk signals — the same checks this guide walks through, without installing anything.
Related
Audit your Node.js dependencies for the same class of supply-chain risk in code you ship.
Install InspectorInspect what a package or install script actually does before it runs on your machine.
Security LabsHands-on browser labs across supply chain, detection and incident response.
All PlayCISO toolsThe full free toolkit — scanners, threat-modeling and risk-register builders.
Frequently asked questions
Which extension permissions are the most dangerous?
The ones that let an extension read and change data on every site you visit are the highest-impact, because they put your banking, email and internal tools in the same trust boundary as the extension. Broad host access (<all_urls>), scripting, webRequest, cookies, clipboard and management permissions all deserve a hard "why does it need this?" If the stated function does not require it, treat the request as a red flag.
Can a trusted extension turn malicious later?
Yes, and it is one of the most common ways users get burned. Extensions auto-update silently and the update keeps the permissions you already granted, so a developer who sells the extension or whose account is compromised can push a version that adds tracking or steals data without you reinstalling anything. Vet the current version, but also keep your installed set small and re-review permissions periodically.
Is installing from the official web store safe?
Safer, but not a guarantee. Official stores run automated and sometimes manual review, which filters out a lot of obvious abuse, yet malicious extensions still slip through and legitimate ones still get taken over after listing. Use the store as a baseline, then apply the permission, host-access and ownership checks in this guide before trusting it with your browsing.
What does obfuscated extension code tell me?
Minification is normal; deliberate obfuscation that hides logic, decodes packed strings or downloads and executes remote code is a warning sign. It means you cannot see what the extension really does, and remote-loaded code can change behaviour after any review. An extension that fetches and runs scripts from a third-party server is one whose future behaviour you cannot vouch for.
How should a company manage extensions across a fleet?
Default-deny and allow-list specific vetted extensions by ID through browser enterprise policy, rather than trying to block bad ones individually. Force-install the approved set, control updates where you can, and re-review the allow-list on a schedule because an approved extension can change ownership or behaviour later. This keeps the attack surface to a known, small, reviewed set.