Keep your extension policy, such as the ExtensionSettings JSON for Chrome, Edge or Firefox, in a repository. Require a pull request, a second reviewer and a pilot rollout for every change. That gives you history, a named approver for each extension and a quick way to roll back.
Why bother
Extension policy is a short JSON document that controls what runs inside every employee's browser. A one-line change can force-install code or allow a risky extension to everyone. Yet it is often edited by hand in a console with no review and no history. Treating it like code fixes that without much effort.
Chrome's policy definition shows the shape: a map from an extension ID, or * for the default, to settings such as installation_mode, blocked_permissions, runtime_blocked_hosts, minimum_version_required and update_url.
{
"*": {
"installation_mode": "blocked",
"blocked_install_message": "Request a review at the IT portal."
},
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa": {
"installation_mode": "force_installed",
"blocked_permissions": ["downloads"]
}
}
The ID above is a placeholder. Use real 32 character IDs in your own file.
A routine that works
- One file per browser and group. Keep Chrome, Edge and Firefox policies in separate files, since the fields differ.
- Pull request for every change. The description must name the extension, the reason, the owner and the review date.
- Two reviewers for force-installs. A force-install is silent on every machine in scope.
- Automated checks. Validate the JSON, check that IDs match the expected pattern, and fail the build if an entry uses
*with a permissive mode. - Pilot first. Apply to a small group and watch for breakage.
- Tag releases. Tag each version so you can state what policy was live on a given date.
What a reviewer should check
| Question | Why |
|---|---|
| Is the ID the right one? | A typo can force-install the wrong extension |
| Is the update URL expected? | A self-hosted URL becomes part of your supply chain |
Does it use *? | Default changes affect everyone |
| Which groups does it target? | Scope should be as narrow as possible |
| Is there an owner and a date? | Otherwise it never gets reviewed |
Evidence for audits
An auditor asking how you manage browser extensions wants to see a defined process, approvals and logs. A repository gives all three: the commit history is the change log, the pull request is the approval and the tag shows the effective policy at a point in time. Do not claim more than the evidence shows, and check requirements with your own auditor.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how a pull request waits on checks before it can merge. Your policy file should work the same way.
Where Safeguard fits
Safeguard's policies, gates and compliance evidence automation fit the same pull request pattern for application code and its dependencies. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need special tooling?
No. A repository with branch protection and a JSON validation step is enough to start.
Who should approve force-installs?
A security reviewer plus the extension owner. One person alone should not be able to push code to every browser.
Sources
Last reviewed: 19 October 2026.
