How to Tell If a Chrome Extension Is Safe: A 7-Step Check Before You Click Install

A browser extension is the most privileged software most people install without reading anything. It executes inside the browser, above the origin boundary that keeps websites apart, and an extension with host permissions can read and rewrite the DOM of every page you load — your webmail, your bank, your company's internal dashboard — without any further prompt after the first.

That is the design, not a flaw. The entire point of a content script is to modify pages. The problem is that the install decision happens in two seconds, based on a star rating, and is then permanent and self-updating.

Here is a procedure that takes five minutes and catches the things that actually go wrong.

Step 1: Read the permission dialog properly

Chrome's install prompt is written for non-technical users, which makes it vaguer than the underlying grant. The translation matters:

Two of those deserve a hard stop on a consumer utility. nativeMessaging means the extension's reach does not end at the browser — it requires a companion host application registered on your OS. debugger grants the Chrome DevTools Protocol, which can read and rewrite anything, intercept network traffic, and evaluate arbitrary script in any tab. Legitimate uses exist, almost entirely in developer tooling, and they are rare enough that seeing either on a colour picker should end the evaluation.

You can always read the real manifest instead of the prose. After installing, open:

chrome-extension://<extension-id>/manifest.json

The permissions, optional_permissions, host_permissions, and content_scripts.matches arrays are the ground truth. Step 7 shows how to read them before installing.

Step 2: Does the permission set match the stated job?

This single question catches more bad extensions than every other signal combined, because malicious extensions overwhelmingly ask for more than their described function needs.

Work it through concretely:

The last row is the archetype. A unit converter needs to read the selected text on the current tab when you click it. An implementation requesting <all_urls> plus cookies is either badly built or doing something it has not told you about, and from the outside those look identical.

cookies combined with host permissions is the pairing that should worry you most, because that is read access to session cookies — bearer tokens that replay an authenticated session without a password or an MFA prompt. The mechanics of why that is worse than a leaked password are in how stolen cookies bypass MFA.

Step 3: Investigate the publisher, not the listing

Click the developer name on the store page and look at what else they publish. Then check four things:

1. Is there a real website, on a real domain? A privacy policy hosted on a free page builder with no company name is a different proposition from one on the product's own domain.
2. Does the support email match that domain? A consumer webmail address as the sole contact for an extension with host permissions on 200,000 browsers is a reasonable thing to decline.
3. What is the other portfolio? One well-maintained extension with a changelog is a better signal than nine single-purpose utilities published in the same month.
4. Is the publisher verified, and is the extension Featured? Chrome Web Store's Featured badge requires a manual review against technical and design criteria, and verified-publisher status requires domain ownership proof. Neither is a security guarantee, and both are meaningfully better than nothing.

Step 4: Read the Privacy practices tab

Chrome Web Store requires developers to declare what data they collect and to certify how they use it. The tab sits next to the reviews and nobody opens it.

Look for three specific declarations:

• "This developer declares that your data is not being sold to third parties, outside of the approved use cases." Absence of this line means the developer did not make that commitment.
• "...is not being used or transferred for purposes that are unrelated to the item's core functionality." Absence here is the one to care about: it is how data brokerage inside a utility extension gets disclosed.
• The collected data categories list — authentication information, personal communications, web history, location. A screenshot tool declaring collection of "web history" and "authentication information" has told you exactly what it does, in a tab you have to click.

These are self-declarations rather than audited facts. Their value is that a false declaration is a policy violation with a takedown attached, so developers tend to disclose rather than lie.

Step 5: Ignore the rating, read the recent one-stars

A 4.6-star average across 12,000 reviews tells you about the extension's past, which is not what you are buying. Install counts and reviews are both purchasable; the useful signal is in the text.

Sort reviews by most recent and read the negative ones, looking for a specific pattern:

• Several reviews within the same short window saying an update started injecting ads, redirecting searches, or opening tabs.
• Long-time users saying the extension "changed hands" or "was sold".
• Complaints that the extension now requires permissions it did not before.
• Reports of unexpected network activity or new companion software.

That cluster is the signature of a compromised or sold extension, and it appears in the reviews days before it appears in a news article.

Step 6: Price in the auto-update risk

Everything above evaluates the extension as it is today. Extensions auto-update, and an update does not re-prompt for permissions already granted.

This is the dominant realistic threat, and it has a well-documented shape. The Great Suspender — a popular tab-suspending extension with millions of users — changed ownership, and the new maintainer shipped code that led to Google removing it from the store and disabling it in users' browsers. Nano Adblocker and Nano Defender were sold, and the new owners pushed an update that the original developer publicly warned about, prompting mass uninstall advice. Neither case required an exploit. Both used the ordinary update channel, which is why no install dialog appeared.

There is a market for this. Developers of modestly popular extensions receive acquisition offers routinely, and the price is driven by install count, because install count is reach into browsers. Separately, publishing accounts get phished — a convincing "your extension violates policy, sign in to appeal" email is enough.

Three mitigations that actually reduce exposure:

1. Minimise standing count. Every installed extension is an independent update channel into your browser. Twelve extensions is twelve chances for a maintainer to be phished.
2. Prefer projects with an auditable upstream. An open-source extension with a public repository and release tags lets anyone compare the shipped bundle against the source. uBlock Origin and Bitwarden are the examples usually cited, for exactly this reason.
3. Restrict site access so an update inherits less. Covered in step 7, and it is the best single action on this page.

Step 7: Download the code and read it

You do not need to install an extension to inspect it. Google's update endpoint will hand you the CRX package for any extension ID.

Get the ID from the store URL — it is the 32-character string at the end — then:

EXT_ID="cjpalhdlnbpafiamejdnhcphjbkeiagm"   # example: uBlock Origin

curl -L -o ext.crx \
  "https://clients2.google.com/service/update2/crx?response=redirect&prodversion=120&acceptformat=crx2,crx3&x=id%3D$EXT_ID%26uc"

mkdir ext && cd ext && unzip -o ../ext.crx

A CRX is a ZIP with a short signature header, so unzip works with a warning. Then read, in this order:

# 1. The real permission set
cat manifest.json

# 2. Which pages get a content script, and when
grep -A10 content_scripts manifest.json

# 3. Where does it talk to?
grep -rhoE "https?://[a-zA-Z0-9._/-]+" . | sort -u | head -40

# 4. Dynamic execution and obfuscation markers
grep -rnE "atob|eval|new Function|Function\(|unescape" .

# 5. Direct reach for sensitive APIs
grep -rnE "chrome.cookies|chrome.debugger|chrome.history|nativeMessaging" .

What you are looking for is not perfect code — bundled and minified output is normal. You are looking for capability that contradicts the description. A note-taking extension whose bundle contains chrome.cookies.getAll and a hardcoded analytics endpoint has answered your question. A list of outbound hosts containing a domain unrelated to the product is worth ten reviews.

atob plus eval in combination is the classic obfuscated-payload marker. Under Manifest V3 remotely hosted code is prohibited and eval is blocked by the default extension CSP, which is a genuine improvement — but chrome.scripting.executeScript with a dynamically assembled function, or a fetch of configuration that drives behaviour, achieves adjacent outcomes within the rules.

For an already-installed extension, the live view is better still: chrome://extensions → Details → "Inspect views: service worker" opens DevTools attached to its background context. The Network tab there shows exactly what it is sending and where.

The thing to do after installing

If you take one action from this page, take this one.

chrome://extensions → Details → Site access → "On click"

This changes the extension from holding a standing grant on every page to requesting access when you click its toolbar icon. The underlying mechanism is the activeTab pattern, and it converts a permanent capability into a per-use one. Most extensions keep working normally; the ones that genuinely need continuous access — content blockers, password managers — are the ones where you can reasonably grant it.

Alongside that:

• Set "On specific sites" for extensions that only matter on a few domains. A vendor-portal helper does not need your webmail.
• Turn on Enhanced Safe Browsing at chrome://settings/security, which adds malicious-extension checks.
• Audit the list quarterly and remove what you have not used. Risk scales with the number of installed extensions, so uninstalling is a security action.
• Look for anything you did not install. On Windows, software can register an extension through the registry, which is how bundled adware arrives. Anything in the list you do not recognise should go.

Run this on every extension, including the ones from vendors you otherwise trust — the one this site publishes included, which is why its security page documents what it requests and why. An extension that cannot survive this checklist is not worth defending, and one that can should be willing to show its working.

Red flags, in one table

For anyone managing a fleet

Enterprise policy makes most of this a configuration decision rather than a user judgement. The relevant keys are ExtensionInstallAllowlist and ExtensionInstallBlocklist for the install decision, ExtensionSettings with runtime_blocked_hosts to prevent any extension from touching named origins regardless of its manifest, and ExtensionInstallForcelist for the ones you require.

runtime_blocked_hosts is the underused one. Blocking every extension from https://*.yourbank.example and your internal domains means a compromised extension cannot reach the pages that matter most, even with <all_urls> granted. Verify what is applied with chrome://policy.

What this comes down to

Extensions are useful and the useful ones need real privilege. The failure mode is not that people install malware deliberately; it is that a two-second decision grants a permanent, self-updating capability, and nobody revisits it.

Permissions versus stated function, publisher accountability, recent negative reviews, and on-click site access. Four of the seven steps, two minutes, and most of the risk.