Optional permissions: a safer default for extension developers

If you build browser extensions, request the minimum at install and ask for more at runtime. Chrome's documentation recommends optional permissions wherever functionality allows, and says permissions limit the damage if an extension is compromised. Fewer install warnings also tend to build user trust.

The four manifest keys

Chrome's documentation describes four related keys:

• permissions: known API strings. Changes may trigger a warning.
• optional_permissions: granted by the user at runtime, not at install.
• host_permissions: match patterns for hosts. Changes may trigger a warning.
• optional_host_permissions: host patterns granted by the user at runtime.

Content script match patterns can also trigger a warning.

Why ask late

Three reasons.

1. Trust. Chrome notes that limited warnings tend to build trust, and recommends optional permissions to avoid alarming users.
2. Containment. The docs say permissions help to limit damage if your extension is compromised.
3. Relevance. A user who clicks a feature and then sees a request understands why you are asking.

Pick the narrowest access that works

Order your choices from narrowest to broadest:

1. activeTab. Temporary access to the current tab, on user invocation, with no install warning. See what activeTab means.
2. Optional host permissions for specific sites, requested when needed.
3. Specific host permissions declared up front for a few domains.
4. Broad host permissions for every site, as a last resort. Chrome notes that all_urls may lengthen store review.

Design the request flow

• Ask in response to a click, with a sentence explaining why.
• Make the feature work in a limited way if the user declines.
• Do not nag. Remember the refusal.
• Explain in the listing what each permission does and why it is needed.

Mind the other security basics

A useful test before each release: diff the manifest permissions against the previous version. Any new entry should have a one sentence reason in your release notes. Users who see a prompt after an update, and find no explanation, are right to be suspicious.

• Keep all logic in the package. Remote code is not allowed under store policy.
• Do not let content scripts pass arbitrary URLs to your fetch logic.
• Use safe DOM methods with fetched content.
• Document your data use in plain words, within the limited use rules. See Chrome Web Store policies for users.

Safeguard's own extension surfaces, as described on its download page, publish their data behavior in plain terms, for example that the free Gold extension never reads page content. That is the kind of statement users can check.

Quick check

Sources

• Declare permissions (Chrome for Developers)
• The activeTab permission (Chrome for Developers)
• Match patterns (Chrome for Developers)
• Permissions manifest key (MDN)
• Safeguard downloads

Last reviewed: 19 October 2026.