Verified CRX Uploads is an opt-in Chrome Web Store setting that requires every future update to be signed with your own RSA key. Google says it can prevent malicious updates if your developer account is compromised. The catch is the private key: where you keep it decides whether the protection holds.
The risk it addresses
An extension's users trust whoever can publish updates. If an attacker gets into the developer dashboard, they can publish a new version, and the browser delivers it. Publishing accounts of extension authors are an attractive target for exactly this reason. Verified uploads separate two powers: access to the dashboard and ability to sign a package.
How it works
From Google's publishing guide:
- It is opt-in, and once on, all future updates must be signed with your RSA key.
- You generate a 2048-bit RSA key pair with openssl, or let Chrome generate one when packing.
- You upload signed CRX files through Upload New Package or the Update API.
Key handling
Google's page is specific about what not to do:
- Do not upload the private key to a public repository.
- Do not store it in your Google Account, because someone with dashboard access through that account could then publish on your behalf.
- If you lose it, you must contact Chrome Web Store support, and replacement can take up to a week.
A reasonable approach is to keep the key in a secrets manager or hardware-backed store that is separate from the identity that owns the dashboard, and to sign in your build pipeline with tightly scoped access. Back up the key somewhere offline, since losing it is costly.
What it does not cover
- It does not help if the attacker steals the signing key.
- It does not help if malicious code lands in your repository and your pipeline signs it faithfully. Protect your source and build as well, with branch protection and review on every change.
- Google's page does not mention two-factor authentication or other account settings, so check those separately and turn on the strongest sign-in options your account offers.
A short checklist
- Turn on verified uploads for every extension you publish.
- Keep the signing key out of the Google account and out of source control.
- Limit who can run the signing job.
- Make a release a reviewed event, with a second person approving.
- Practice your response plan: unpublish, rollback, notify users. See what to do after a bad extension.
Common mistakes
The common failure is keeping the signing key next to the thing it protects, such as in the same account or the same repository. Another is signing from a laptop with no record of who did it. Move signing into a controlled job and log every run.
Quick check
Does Verified CRX Uploads replace account security?
No. It adds a second barrier. Google's page does not discuss sign-in protection, so keep that strong too.
Where should the private key live?
Not in a public repo and not in the same Google account that owns the dashboard, per Google's guidance.
Sources
Last reviewed: 19 October 2026.
