How to analyze a browser extension: store, manifest and code

Most extensions you will vet live on the official store for that browser (for example Chrome Web Store for Google Chrome). Open the listing and work through a short checklist:

• User count — Very few extensions reach millions of users; a large audience can indicate maturity, but absence of users is not proof of malice.
• Reviews — Many people never review extensions. Lots of glowing reviews with almost no installs can suggest manipulation; on popular items, complaints are often about pricing or support, not security—still read recent negatives for behavior changes.
• Owner / publisher, support, privacy policy, and terms — If data can be sold to third parties under the terms, that is a policy problem even when the code looks fine. Broken or generic legal pages deserve extra scrutiny.
• Last updated — Stale code can mean abandoned software or a dormant takeover risk; frequent updates need a process to re-review.

Installed Chrome extensions sit on disk under a folder named by extension ID, with a version subfolder. Typical paths:

• Windows: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Extensions
• macOS: ~/Library/Application Support/Google/Chrome/Default/Extensions
• Linux: ~/.config/google-chrome/Default/Extensions

To fetch a CRX without installing through the UI, use a small downloader script or trusted internal tooling your security team approves. Microsoft Edge can be pulled with a direct URL pattern; after download, treat the file as a zip archive and unpack it (often unzip works on renamed or extracted payloads).

The manifest tells the browser what the extension may do. Open the root manifest.json and focus on:

• manifest_version — Prefer MV3; MV2 is deprecated.
• permissions and optional_permissions — Map each entry to real product needs; map each permission to what the product actually requires using your browser vendor's extension permission documentation as the rubric.
• host_permissions — Broad patterns like <all_urls> are sometimes justified; you need a written why.
• background — Service worker scope for persistent logic.
• content_scripts — What runs inside web pages and on which matches.
• declarative_net_request — Static rules that can block, redirect, or modify requests without obvious JS—review rule sets, not only scripts.

• Minified or obfuscated bundles — Use a code formatter or deobfuscation utility when you need readability; legitimate vendors also ship compact code, so context matters.
• Browser APIs — Search for calls like chrome.tabs.captureVisibleTab, chrome.cookies, clipboard, debugger, or webRequest variants and tie them to stated features.
• Network — Grep for fetch, XMLHttpRequest, WebSocket, and third-party SDKs; endpoints are often easier to spot than hidden logic.
• Dependencies — Check versions and known CVEs; libraries that never update hint at maintenance risk.

After go-live, keep an eye on:

• New versions—auto-updates can change behavior overnight.
• Publisher or ownership changes.
• Delisting, “private” listings, or policy enforcement actions.
• IOCs and domain overlap with known bad infrastructure.
• Shifts in review sentiment or sudden spikes in permissions.
• Correlated signals across many extensions (copy-paste malware campaigns).

Tooling that inventories extensions, diffs updates, and flags high-risk permissions helps at scale—eSafe on the desktop is aimed at individuals who want continuous extension visibility and safer checkout flows, not a full enterprise admin console, but the habits are the same: least privilege, verify updates, remove what you do not need.