A plugin permission manifest is a file shipped with a plugin that declares which data, APIs and network destinations it needs. The host reads it, shows it to the user or admin, and enforces it at runtime. Without one, every plugin gets the host's full power by default.
Why a manifest beats trust by reputation
If your product accepts third-party plugins, you have two options. You can judge each plugin by who wrote it, or you can limit what each plugin can do. The first does not scale. The second does, and the manifest is where the limit is written down.
Chrome's extension documentation states the idea directly: to use most extension APIs, an extension must declare its intent in the manifest, and permissions help limit damage if the extension is compromised by malware. That second half matters. A declared, enforced permission list turns a compromised plugin from "can do anything" into "can do what it asked for."
What a good manifest declares
Chrome splits requests into several keys: permissions for known API strings, host permissions as match patterns for sites, and optional versions of both that are granted by the user at runtime. Figma's plugin model adds another useful field: a list of network domains. When a plugin limits network access and then tries to reach a domain not in its manifest, Figma blocks the request with a content security policy error.
| Declaration | What it answers | Design note |
|---|---|---|
| Data scopes | Which of the user's records can it read or write? | Separate read from write |
| Host or domain list | Where can it send data? | Prefer exact domains over wildcards |
| Sensitive APIs | Can it run processes, read files, touch credentials? | Treat each as a review trigger |
| Optional permissions | What can wait until the user enables a feature? | Ask at the moment of use |
Atlassian's marketplace requirements add a rule worth copying: an app must follow the principle of least privilege and request only the scopes required for its intended function, nothing more.
Steps to introduce a manifest in your product
- List every capability your plugin API exposes today, including indirect ones such as network, clipboard and local storage.
- Group them into tiers. Low-risk items need no prompt. High-risk items need explicit consent.
- Make the manifest the only way to get a capability. If a plugin can call an API without declaring it, the manifest is decoration.
- Enforce at runtime in the host, not in a review checklist alone. Block the call and log the attempt.
- Show a plain-language summary on the install screen and again whenever the list grows.
- Offer optional permissions so features can be switched on later with context.
Common mistakes
Wildcards are the usual one. Chrome's own review guidance names patterns such as all URLs as broad host permissions that give extensive access to a user's web activity, and says they make review slower. If a wildcard is truly needed, make that visible to admins.
Another mistake is a manifest that never gets re-checked. Plugins grow. Compare each new version's declared permissions against the last one and flag the difference for review.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice how each component carries its own version and source. A plugin manifest deserves the same treatment: one record per plugin, with declared access next to it.
Quick check
Is a manifest enough to make a plugin safe?
No. A manifest limits what a plugin can ask for, but safety also needs runtime enforcement, review of what the code actually does, and a way to remove a plugin quickly.
Should every permission be optional?
No. Core features can be required. Anything a user may never need, such as access to extra sites, is a good candidate for an optional grant requested at runtime.
Safeguard fits at the dependency end of this problem. Plugins ship with their own libraries, and SBOM and dependency scanning plus policies and gates let a team see and control what a plugin pulls in. You can try the free scan on a plugin's manifest and lockfile.
Sources
- Declare permissions, Chrome Extensions
- How Plugins Run, Figma Developer Docs
- Security requirements for cloud apps, Atlassian
- Chrome Web Store review process
Last reviewed: 19 October 2026.
