A malicious extension could read every password your team types and every document they open. Catching it does not take a malware lab. Below is the methodology we use at Ostral, and the first steps are ones you can run yourself. The trick is not to spend hours in the code, but to compare what an extension does with what it asks for. A genuine tool asks for roughly what its job needs; a liability asks for far more, and that gap is the loudest signal you get.
1. Get the permission list
You will not have the extension's source code, and you do not need it. What every extension must declare is its permissions, and those are public. You can pull them without installing anything:
The store listing. The Chrome Web Store and Edge Add-ons both show a "This extension can" section that spells out the access it requests.
The browser's own details page. On any machine that already has it, open
chrome://extensions, then Details, for the permissions and site access in plain language.A catalogue such as Chrome-Stats (chrome-stats.com), which records each extension's permissions, version history, and ownership changes over time, so you can check one you have never installed.
Note especially any access to all sites, and any powerful permission such as proxy, webRequest, cookies, tabCapture, or debugger. The permission dictionary lists what each one grants.
2. Compare permissions to the stated function
One question does most of the work. Does the tool need this access to do its job? A color picker that wants proxy control and access to every site is not a color picker, and most malicious ones are caught right here, before anyone reads a line of code.
3. Check the publisher and its history
Who publishes this, really? Check the developer name, the support site, and whether the contact details look real, then look for ownership changes. A trusted extension that quietly changed hands is the classic setup, an anonymous new owner inheriting a large, trusting base.
4. Read the update history and cadence
Extensions update silently, so the timeline matters. Did a recent version add permissions it never had before? A jump from a narrow scope to "all sites" between versions is worth blocking on alone.
5. Read the store signals critically
Install count, rating, and reviews give context, not proof. A big install count only means many people installed it; some of the worst extensions had millions of users. Read the recent one and two star reviews, where users often flag the moment a tool went bad.
6. The code layer, which we automate
The steps above are the public checks any CISO can run. The last layer is reading the actual JavaScript, which most teams cannot do at scale by hand. This is the part we automate at Ostral, and here is what that analysis looks for:
What to look for in the code | Why it matters |
|---|---|
Calls to remote servers ( | Possible exfiltration of what the user sees and types |
Dynamic code execution ( | The published code is not the code that runs; behavior can change remotely |
A remote configuration or PAC file fetched on startup | Behavior is server-controlled and can flip with no visible update |
Rewriting of links or page content ( | Link hijacking, affiliate fraud, or content tampering |
Hardcoded third-party or tracker domains | Data is going somewhere the tool never disclosed |
Heavy obfuscation with no legitimate need | Deliberate effort to hide what the code does |
A worked example
Take one we analyzed: a translator called Huiyi, useful and popular, with tens of thousands of users. Its permission list includes monitoring web traffic and changing proxy settings, which no translator needs. Its code pulls a proxy configuration from a remote server at startup, so the operator can reroute traffic whenever they like, with no visible update.
The tool is useful, so people keep it. That is what makes it effective.
You did not need to be a malware analyst to flag it. Step 2 caught it: a translator asking to reroute network traffic. Everything after that was confirmation.
Turn the finding into a decision
An examination should end in one of three outcomes, not in a note that says "looks suspicious":
Allow. The access fits the function, the publisher is credible, and the update history is clean. Record why, so the next reviewer does not start over.
Replace. The function is needed but this tool is the wrong way to get it. Provide a sanctioned alternative so users are not left reaching for another unknown extension.
Block. The gap between function and access is unexplained, the publisher is opaque, or an update escalated permissions. Block by ID across every browser.
Your verdict expires without warning. A clean verdict is true only for the version you checked, and the next silent update can undo it. One extension is an afternoon. Every extension, re-checked on every update, is a job that never ends.
Examine every extension, on every update, automatically
Ostral runs this examination continuously on every extension in your fleet: permission fit, publisher and ownership history, update behavior, and static code analysis for exfiltration, dynamic execution, and tracker domains. Each extension gets a risk score and a clear allow, review, or block recommendation, and it is re-checked the moment a new version ships.
