Chrome checks each installed extension's update URL every few hours, reads an update manifest, and installs any newer version that is signed with the same private key as the current one. Store extensions use the Chrome Web Store URL by default. Self-hosted ones use whatever URL you set.
The update loop in four steps
Chrome's documentation for self-hosted extensions describes the flow:
- Every few hours the browser looks at each installed extension's update URL.
- It requests an update manifest, an XML file listing the latest version.
- If that version is newer than the installed one, it downloads the new
.crxfile. - The new file must be signed with the same private key as the installed version.
The documentation also notes that Chrome does not send cookie headers with these manifest requests, to protect user privacy. That is useful to know if you were planning to gate the update server by session.
Where the URL comes from
In the force-install list, each entry is an extension ID and, optionally, an update URL separated by a semicolon. The Chromium policy definition says the Chrome Web Store update URL is the default, and that a custom URL should point to an update manifest XML document.
| Path | Update source | Who controls the release |
|---|---|---|
| Store extension | Chrome Web Store | The publisher, after store review |
| Self-hosted extension | Your own web server | Whoever can write to that server |
What this means for your risk model
With a store extension you depend on the publisher's account and the store's review. With a self-hosted one you depend on your own hosting and your signing key. Neither is automatically safer. The question is which failure you are better placed to prevent.
For self-hosted updates, the signature rule is a real protection: someone who replaces the file on your web server cannot ship a working update unless they also hold the private key. So the web server and the key are two separate things to defend. The key matters more.
For store updates, you have little control over timing. Policy fields such as minimum_version_required exist in the schema to enforce a floor, but there is no field in the schema we reviewed that holds back a new version. If you need to pause a release, the route is to block or remove the extension, which we cover in the staged rollout and rollback post.
A practical checklist
- Know which update URL each forced extension uses.
- For self-hosted ones, serve the update manifest and the file over HTTPS. The policy accepts http, https and file schemes, but HTTPS is the sensible choice for anything leaving a lab.
- Restrict who can write to the update server and log changes.
- Store the signing key off the web server.
- Watch for version changes on a schedule rather than waiting for an incident.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the alerts and notice how a change after an initial clean result is what gets flagged. The same idea applies to extension versions.
Quick check
How often does Chrome check for extension updates?
The documentation says every few hours. It does not give an exact interval, so do not plan around a specific number.
Can an attacker push a fake update to a self-hosted extension?
Not without the private key, because the new package must be signed with the same key as the installed version. Protect the key as carefully as the server.
Sources
Last reviewed: 19 October 2026.
