cwspy.com · August 14, 2026 · 7 min read
Chrome Extension Permissions Explained (and What Gets You Flagged)
Chrome extension permissions are the single most common reason a submission gets extra scrutiny in review, and one of the clearest signals users read before installing anything. Manifest V3 made the split between general permissions and site-access (host_permissions) explicit, which means what you ask for is more visible than it used to be — to reviewers, to users, and to IT admins deciding whether to allow an extension in a managed environment.
permissions vs. host_permissions
| Field | Covers | Example |
|---|---|---|
| permissions | Chrome API access — storage, tabs, notifications, alarms, and similar capabilities | "permissions": ["storage", "tabs"] |
| host_permissions | Which sites/origins the extension can read or interact with | "host_permissions": ["https://*.example.com/*"] |
| optional_permissions | Permissions requested at runtime instead of at install, only when actually needed | "optional_permissions": ["downloads"] |
Manifest V2 blended API access and site access into one undifferentiated list, which is part of why Manifest V3 review and enterprise policy tools treat host_permissions as its own, more sensitive category — broad site access is the thing most likely to worry a reviewer or an IT admin, independent of what API permissions you also request.
Why "all urls" gets extra scrutiny
Requesting <all_urls> in host_permissions is sometimes genuinely necessary — a general-purpose ad blocker or a password manager has a real reason to run everywhere. But it is also the single request most likely to trigger closer store review, a scarier permission prompt for users, and outright blocking by enterprise policy admins screening what to allowlist for their organization (see our enterprise policy guide for that side of it).
Every permission you request should be traceable to a specific feature a reviewer, a user, or an admin can point to. "We might need it later" is not a justification that survives review, and it is not one that survives a user reading the permission prompt either.
A practical permissions audit
- List every permission and host_permissions entry in your current manifest, and next to each, write the one feature that requires it.
- Anything you cannot name a feature for, remove — dead permissions from an old feature are the most common source of unnecessary scope.
- For anything used only occasionally, move it to optional_permissions and request it at the moment the feature is used, not at install.
- Scope host_permissions as narrowly as the feature allows — a specific domain pattern instead of <all_urls> where possible.
- Re-run this audit after every feature addition or removal, not just once — permission scope tends to only grow unless someone deliberately prunes it.
What over-broad permissions cost you
- Slower or rejected review — Manifest V3 submissions with broad host_permissions get closer scrutiny, which can add real time to how fast an update goes live.
- Lower install conversion. A scarier permission prompt at install time measurably suppresses install rate, independent of everything else about your listing.
- Blocked from enterprise allowlists before an admin even evaluates the rest of the extension.
- Getting flagged as one of the causes an extension is disabled or pulled — see our guide on what makes an extension "no longer supported" for the other side of this.