A blocklist value of * in Chrome's ExtensionInstallBlocklist policy blocks all extensions by default. Extensions on the allowlist are permitted if they are signed (packed), all unpacked extensions are blocked, and anything already installed but not allowed is disabled with no way for the user to turn it back on.
What the policy definition says
The Chromium definition for ExtensionInstallBlocklist states that extensions already installed will be disabled if blocked, "without a way for the user to enable them." Once an extension is removed from the blocklist, it is re-enabled automatically. A value of * means all extensions are blocked by default, extensions explicitly in the allowlist are allowed if they are signed, and all unpacked extensions are blocked. If the policy is not set, users can install any extension.
The three effects people forget
- Existing extensions go dark. Turning on the wildcard does not just stop new installs. Everything installed and not allowlisted is disabled at the next policy refresh. Plan the cutover so that useful tools are already on the allowlist.
- Unpacked extensions stop working. Developers who load unpacked extensions for testing will find them blocked. Extension developers and anyone who tests an internal extension need an exception path.
- Data stays behind. Disabling is not deleting. The extension and its stored data remain on the machine until it is removed. We cover what that means in the post on blocked versus removed extensions.
Default allow or default deny
| Approach | Strength | Cost |
|---|---|---|
| Default allow, block known bad | Low friction | You are always behind the next malicious listing |
| Default deny with an allowlist | Only reviewed extensions run | Needs a request process and review capacity |
| Default deny for most, allow low-risk categories | Balanced | Needs clear category rules |
Default deny is the stronger posture for developer fleets and for anyone handling production access. It only works if requests are answered quickly. If waiting takes a week, people find workarounds, such as a personal browser profile on an unmanaged machine.
A rollout in five steps
- Inventory what is installed today, per user and per extension ID.
- Review the top extensions by number of installs and mark each approve, restrict or reject. A decision guide helps.
- Add approved IDs to the allowlist.
- Switch the blocklist to
*for a pilot group first. - Watch request volume for two weeks, then widen.
Test before you broaden
On a pilot machine, check three things: an allowlisted extension still works, a blocked one shows the blocked state, and an unpacked extension is refused. Write down the results so the audit file shows you tested the policy, not only wrote it.
For the company-wide setup in detail, see how to block Chrome extensions company-wide.
Quick check
Does the wildcard blocklist remove extensions?
It disables them. The policy definition says blocked extensions already installed are disabled and the user cannot enable them. It does not say they are uninstalled.
Does force-install still work with a wildcard blocklist?
Yes. The force-install policy definition says it supersedes the blocklist policy, so forced extensions install even when the blocklist is *.
Sources
- Chromium policy definition: ExtensionInstallBlocklist
- Chromium policy definition: ExtensionInstallForcelist
Last reviewed: 19 October 2026.
