Safeguard
Security Guides•

How to block or allow Chrome extensions company wide

Admins can control Chrome extensions by ID with the ExtensionSettings policy: allow, block, remove or force install, and block by permission. Here is how.

Safeguard Security Team
3 min read

Chrome administrators control extensions with the ExtensionSettings policy. You set a default, then per extension rules by ID: allowed, blocked, removed, force installed or normal installed. You can also block extensions that request specific permissions. This lets a team run an approved list instead of trusting every install.

The building blocks

Google's admin documentation describes ExtensionSettings as the policy that overrides older install policies if they are also set. Each extension is configured by its ID, and a star entry sets the default for extensions without a custom rule.

The main control is installation_mode:

  • allowed: users can install it. This is the default if none is set.
  • blocked: users cannot install it.
  • removed: users cannot install it and Chrome removes it if already installed. Needs Chrome 75 or later.
  • force_installed: installs automatically and users cannot remove it. Needs an update URL.
  • normal_installed: installs automatically but users can disable it. Needs an update URL.

Force and normal install cannot be used with the star default.

A sensible allowlist approach

The documentation does not spell out an allowlist recipe, but the fields suggest one. Set the default to blocked, then set specific IDs to allowed. Test this in a pilot group first and confirm behavior against Google's current documentation, because policy details change.

Block by permission

The blocked_permissions field stops extensions that request listed API permissions from installing or running. If a blocked permission is required, the extension will not install, and installed copies stop loading. If the blocked permission is optional, the extension installs but Chrome declines that permission.

This is useful for risky capabilities. A team might block the permission that manages other extensions, or the one that talks to native applications, then grant exceptions case by case.

Other fields worth knowing

  • blocked_install_message adds custom text to the error, so users know whom to ask.
  • runtime_blocked_hosts and runtime_allowed_hosts restrict which sites extensions can touch, up to 100 entries each.
  • minimum_version_required disables extensions older than a version, which helps after a known bad release.
  • install_sources and allowed_types are default only settings.

Process matters more than policy

Rolling out a block list on day one tends to break workflows people did not tell you about. Run in a pilot group, collect the extensions people actually use, approve the sensible ones, and only then tighten the default. Keep a written record of why each ID was allowed, so the next reviewer does not start from zero.

A block list without a request path creates shadow IT. Publish a short process: who approves, what you check, how long it takes. Our extension policy template gives a starting point.

Quick check

Does blocking by permission also remove installed copies?

For a blocked required permission, previously installed copies stop loading. For an optional one, the extension still installs but Chrome declines that permission.

Can I force install with the default entry?

No. The documentation says force_installed and normal_installed cannot be used with the star key.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.