When you review a self-hosted browser extension, check four things: the update URL in the policy, whether it uses HTTPS, who can write to the server behind it, and whether packages are signed with the key you expect. Chrome accepts http, https and file URLs for force-install, but only HTTPS is a sensible choice over a network.
What the update URL does
In Chrome's force-install policy each list item is an extension ID and, optionally, an update URL separated by a semicolon. The URL should point to an update manifest XML document. If none is given, the Chrome Web Store's update URL is used. Chrome's self-hosting guide says the browser checks installed extensions for an update URL every few hours, requests the manifest, and installs a newer version if one is listed, provided the new package is signed with the same key.
There is also an override_update_url field in the ExtensionSettings schema. We did not find an explanation of it in the schema text, so read the current policy page before using it.
The review checklist
| Check | What good looks like |
|---|---|
| URL scheme | HTTPS, with a valid certificate |
| Hostname | A domain you own and monitor, not a shared or temporary host |
| Write access | A short, named list, with changes logged |
| Manifest content | Lists only the versions you published |
| Package signature | Signed with the expected key, same as the installed version |
| Version history | Old packages kept so you can roll back and investigate |
| Privacy | No cookies are sent on manifest requests, so do not rely on session checks |
Why each check matters
Scheme. Over plain http, anyone on the path can read or alter the manifest. The signature rule limits what they can ship, but they can still cause failed or blocked updates. Use HTTPS.
Hostname. A forgotten domain can be re-registered by someone else. If your update URL points to a host you no longer control, treat that as an incident. The same goes for cloud storage buckets that were deleted.
Write access. The update server decides which version people receive. Anyone who can change it can at least decide timing and rollback. Review access like you would for a deploy system.
Signature. The documented rule that new packages must be signed with the same private key as the current one is your main technical protection here. Guard the key. See protecting the signing key.
Monitor it
Fetch the update manifest on a schedule, compare the version against your release record, and alert on an unexpected change. Also check the certificate expiry on the host. A lapsed certificate silently stops updates, which leaves fleets on old, possibly vulnerable versions.
When something looks wrong
- Stop forcing the extension to new groups.
- Compare the served package to your build output.
- If the file differs, block the extension and rotate the key, as in the response guide.
- Preserve logs from the update host.
Quick check
Does Chrome require HTTPS for the update URL?
The force-install policy definition lists http, https and file as allowed schemes. HTTPS is our recommendation, not a Chrome requirement.
Who should own the update server?
The team that owns the extension, with access reviewed like any deployment system.
Sources
- Chromium policy definition: ExtensionInstallForcelist
- Chromium policy definition: ExtensionSettings
- Chrome for Developers: Self-host for Linux
Last reviewed: 19 October 2026.
