A workable extension policy for a development team fits on one page: approve extensions by ID, ban a short list of risky permissions, review quarterly, and keep a named owner. Below is a template you can adapt, with notes on which browser controls enforce each line.
Scope
State which browsers and which profiles the policy covers. Developer machines are usually the highest risk, since browsers there hold sessions for source hosting, cloud consoles and package registries.
Template
1. Approved list. Only extensions on the approved list may be installed on company managed browsers. The list stores extension IDs, the approver, the date and the purpose.
Enforcement: Chrome's ExtensionSettings policy supports allowed, blocked, removed and force installed modes per extension ID, with a default for the rest.
2. Request process. Anyone may request an extension through a ticket naming the extension, the reason and the alternatives considered. Target a decision within a few working days.
Enforcement: set a custom blocked install message that points to the ticket form.
3. Review criteria. The reviewer checks: single clear purpose, publisher identity, permissions versus purpose, privacy statement, data destinations, and recent update history.
4. Restricted permissions. Extensions requesting any of these need written approval from security: reading clipboard data, managing other extensions, communicating with native applications, reading full browsing history, or access to all sites.
Enforcement: Chrome can block extensions by requested permission.
5. Site restrictions. Extensions may not run on the following sites: production cloud consoles, the identity provider, and the source hosting admin pages.
Enforcement: Chrome supports runtime blocked hosts, up to 100 entries.
6. Separate profiles. Use a separate browser profile for personal browsing and for any experimental extension work.
7. Updates and permission changes. Any permission change that triggers a prompt must be reported to the owner before accepting. Chrome disables an extension until the user accepts new warning permissions.
8. Review cadence. The list is reviewed every quarter. Unused extensions are removed.
9. Offboarding. On departure, sessions and tokens are revoked, and browser profiles are wiped from company devices.
10. Incident handling. A suspected malicious extension is removed, reported to security and handled as an incident. See what to do about a malicious extension.
Make it stick
- Keep the approved list short. Under twenty is easier to maintain than two hundred.
- Prefer extensions that use narrow access, such as activeTab, over broad host permissions.
- Do not forget developer tool extensions for IDEs. They sit outside the browser but carry similar risk.
Quick check
Do we need this if we already use SSO and MFA?
Yes. An extension with page access can read what you can read after you log in. MFA protects the login, not the session an extension sees.
Can this apply to Firefox and Safari?
The policy text can. The enforcement notes here come from Chrome's admin documentation. Check each browser's own management options.
Sources
- Manage extensions in Chrome (Google Chrome Enterprise Help)
- Permission warnings (Chrome for Developers)
- The activeTab permission (Chrome for Developers)
Last reviewed: 19 October 2026.
