A five-part safety checklist

Start with the publisher and listing. Look for a real website, a support channel and a privacy policy that names the data collected. Then inspect the package with a static analyzer.

Focus on host access, sensitive APIs, content scripts, remote code indicators and external domains. Finally, consider update behavior and whether you can live with the access after future changes.

  1. 1

    Identify the publisher

    Prefer recognizable developers with a documented support path.

  2. 2

    Match permissions to features

    Unused powerful permissions are a warning sign.

  3. 3

    Review website access

    Narrow hosts are safer than all_urls for a niche tool.

  4. 4

    Read code findings

    Check dynamic code, remote scripts, cookies and messaging.

  5. 5

    Plan for updates

    Re-check permissions after major versions and remove unused add-ons.

Related pages:browser extension privacy checkerhow to audit an extension

Signals that deserve extra caution

Be cautious when a simple utility requests all_urls, cookies, debugger, nativeMessaging or proxy access; when the privacy policy is missing or vague; when the update URL is not HTTPS; or when the package contains obfuscated code and remote script references.

These signals are not proof of malice. They are reasons to slow down, look for alternatives and ask the publisher questions.

Related pages:what does all_urls meanremote script detector

What a static report cannot tell you

It cannot prove runtime behavior, account access or data transmission. It also cannot see code loaded after installation. If the stakes are high, use a separate browser profile and monitor requests with developer tools.