When someone asks to install a browser extension at work, you have three answers: approve, approve with restrictions, or reject. Decide using five questions about need, permissions, publisher, data use and available controls. Write the answer and the reasons down so the next request is faster.
1. Is there a real need?
If the task is a one-off, a web page may do the job. If the extension replaces a manual process, note the time saved. A vague "it looks useful" is a reason to wait.
2. Do the permissions match the purpose?
Compare what it asks for with what it claims to do. The store rules say extensions should request the narrowest permissions needed, and should not request permissions for features not yet built. A mismatch is a strong signal. See permission warnings decoded and match patterns.
3. Who publishes it?
Look at the developer name, the website, the support channel and the history of the listing. Check whether it is open source. A store listing alone is not a safety mark, as our myth versus fact post explains.
4. What happens to data?
The Chrome Web Store policy requires data collection limited to what the single purpose needs, and a public statement that use complies with its limited use rules. Read the privacy practices on the listing. If it handles page content, credentials or browsing history, the bar goes up. Mozilla's add-on policies similarly limit transmission to what functionality requires.
5. What controls can you apply?
Often the answer is not a flat yes or no. Options include:
- Limit site access to specific sites or on-click only.
- Block specific API permissions through policy, or keep the extension away from your most sensitive hosts. See the runtime controls guide.
- Force a minimum version once a fix is known.
- Approve only for a named group, not everyone.
Putting it together
- Approve: clear need, narrow permissions, known publisher, limited data use.
- Approve with limits: good need, but wide access that policy can narrow.
- Reject: permissions out of line with the purpose, an unclear publisher, or data use you cannot accept.
Record the decision, the reviewer, the date and a review date. Revisit after permission changes. An update prompt is a natural trigger.
Common mistakes. Reviewers sometimes approve based on download counts or ratings, both of which can be manipulated and neither of which says anything about permissions. Another is approving once and never looking again. Use the permissions and the publisher history as the main evidence, and set a review date.
Quick check
Should every request get the same review depth?
No. Scale it to the access requested. An extension that works only on one site you do not care about needs less than one that can read all pages.
What if the developer is a one-person team?
That is not disqualifying, but weigh the risk of abandonment or a sale. Set a review date and keep a replacement option in mind.
Sources
Last reviewed: 19 October 2026.
