No. An update that adds permissions should not apply silently. Hold it until the user or an admin approves the new access, keep the old version running if possible, and treat the change as a review event. Chrome already works this way for permissions that trigger a warning.
Why updates are the real risk
Installing a plugin is one decision made once. Updating is a decision made repeatedly, often with no human involved. That is exactly how a trusted plugin turns hostile: an ownership change or a stolen publisher account, followed by an update that adds access.
Chrome's permission warning guidelines describe the guard. When a new permission that triggers a warning is added, the extension is disabled until the user accepts it. Chrome also notes that adding or changing match patterns in host permissions or content script matches triggers a warning.
What your update policy should cover
| Change in the new version | Suggested handling |
|---|---|
| New sensitive permission | Pause until approved, show a plain summary |
| Wider host or domain list | Same as above |
| New network destination | Flag for review, notify admins |
| New bundled dependency | Scan before release, record in inventory |
| Code size jump or new obfuscation | Route to a human reviewer |
| Version change only, same permissions | Auto update is fine |
Verify the package, not just the permissions
Permissions are one signal. Integrity is another. The Visual Studio Marketplace signs all extensions when they are published, and VS Code checks the signature on install to verify integrity and source. Mozilla's policies add that a new version submitted after corrections should not contain unrelated changes, because they complicate review.
For enterprises, pinning matters. VS Code lets admins allow extensions by publisher, extension and specific version, with no version ranges, and it disables an installed extension if its version is later blocked. That gives a team control over when a change reaches users.
Steps to design update trust
- Store the approved permission set with each installed plugin.
- On update, compare the new manifest against the stored set.
- If anything widens, hold the update and keep the previous version active until approved.
- Verify the package signature before applying any update.
- Offer admins version pinning and a delay window for critical environments.
- Log every update with the permission diff, and alert on the unusual ones.
What about security fixes?
Holding updates has a cost. If a patch for a vulnerability is stuck waiting for approval, users stay exposed. Separate the two cases: updates with no permission change flow automatically, so fixes arrive fast, while permission changes wait. This split is the main reason to compare manifests rather than blocking all updates.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a monitored component is re-evaluated as new information arrives. Update trust needs the same habit: check again after every change.
Quick check
Do all updates need approval?
No. Only changes that widen access or add new risk need a human. Updates with the same permissions can flow automatically so security fixes are not delayed.
Is a valid signature enough to trust an update?
No. A signature shows who published the package and that it was not altered. A compromised publisher can sign a harmful update, so permission and behavior checks still apply.
Safeguard's dependency scanning and policies can evaluate each new plugin build before release, and the free scan is a way to try it.
Sources
- Permission warning guidelines, Chrome Extensions
- Extension runtime security, Visual Studio Code
- Manage extensions in enterprise environments, Visual Studio Code
- Add-on Policies, Firefox Extension Workshop
Last reviewed: 19 October 2026.
