Restrict add-on types when you want a fleet limited to what you have reviewed, but treat it as a minor control. Firefox's allowed_types setting, which is only valid under the * default, limits add-ons to dictionary, extension, locale, sitepermission and theme, and removes installed add-ons of unlisted types at startup.
What the setting does
Mozilla's documentation for ExtensionSettings says allowed_types can only be set in the * entry. It restricts add-on types to those you list, from dictionary, extension, locale, sitepermission and theme. It applies only when installation is not blocked, and at startup Firefox removes installed add-ons whose types are not listed. Per-ID entries set to allowed, force_installed or normal_installed are not restricted by it.
Chrome's ExtensionSettings schema has an allowed_types field in its default scope as well, and its example uses a hosted_app value. We did not review the full list of Chrome types, so check the current policy page.
Is it worth it?
Not all types carry the same risk. An extension runs code with access to pages. A theme changes appearance. A dictionary adds words. The risk is concentrated in extensions, so the highest value comes from controlling those with install modes, not from filtering types.
| Type | Typical risk to review |
|---|---|
| extension | High: runs code, can request broad permissions |
| theme | Low, but still third-party content |
| dictionary | Low |
| locale | Low |
| sitepermission | Review when used, since we did not confirm its details |
Restricting types makes sense when:
- Your policy is default-deny and you want one more tripwire against unexpected add-on forms.
- You have a compliance requirement to enumerate what can be installed.
- You want startup cleanup to remove oddities left by users.
It matters less when you already block * by installation mode, since that stops new installs of every type.
An approach
- List the add-on types you actually use. Most fleets use only extension.
- Decide whether themes and dictionaries should stay for user comfort. Often yes.
- Set
allowed_typesunder*to those you need. - Remember that per-ID entries in the allowed or installed modes are not restricted, so a forced extension still installs even if its type were not listed. Review your explicit entries separately.
- Test on a pilot machine before rollout.
Caveats
- It removes things. The startup cleanup will remove installed add-ons of unlisted types. Warn users before the change.
- It is not a substitute for review. An allowed extension is still code you must vet.
- Behavior depends on version. Mozilla's documentation includes version-specific notes. Match them to your fleet.
For the mode settings that do most of the work, read managing Firefox extensions with policy.
What to tell staff
Before enforcing, send a short note: which add-on types will remain, that other types installed on their profile will be removed at the next restart, and where to ask for an exception. People rarely mind losing a theme if they were warned. They do mind a surprise.
Quick check
Does allowed_types stop a force-installed extension?
No. Per Mozilla's documentation, per-ID entries set to allowed, force_installed or normal_installed are not restricted by it.
Where can I set allowed_types?
Only in the * entry, according to Mozilla's documentation.
Sources
Last reviewed: 19 October 2026.
