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
Identify the publisher
Prefer recognizable developers with a documented support path.
- 2
Match permissions to features
Unused powerful permissions are a warning sign.
- 3
Review website access
Narrow hosts are safer than all_urls for a niche tool.
- 4
Read code findings
Check dynamic code, remote scripts, cookies and messaging.
- 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.