extension-security-and-permissions

name	extension-security-and-permissions
description	Review Chromium extensions for least-privilege permissions, safe host access, CSP and remote-code compliance, and narrow resource exposure. Use when adding permissions, auditing a manifest, preparing a store review narrative, or tightening extension security boundaries.

Extension Security and Permissions

Overview

Permission requests are product surface. Every manifest capability, host scope, and exposed resource should map back to a real feature the user can understand. Design for least privilege first, then write implementation around that budget.

Read these references as needed:

• references/least-privilege.md for manifest permission minimization
• references/remote-code-and-csp.md for MV3 code loading constraints
• references/web-accessible-resources.md for exposure control

Core workflow

1) Enumerate capabilities before permissions

• List the exact browser APIs the feature needs.
• List the exact sites or origins it must touch.
• Challenge each permission before adding it to the manifest.

2) Choose the narrowest host access model

• Prefer activeTab for user-invoked actions on the current tab.
• Prefer optional host permissions if the feature only applies to some sites.
• Use broad host access only when the product genuinely requires background or always-on behavior across many sites.

3) Audit code loading and CSP assumptions

• Keep executable code bundled with the extension package.
• Do not rely on remotely hosted code or dynamic execution patterns MV3 blocks.
• Review any asset, iframe, or fetch path that crosses origin boundaries.

4) Tighten exposure surfaces

• Limit web_accessible_resources to the minimum set of paths and match rules.
• Keep externally reachable pages or bridge scripts narrow and documented.
• Avoid making generic internal assets reachable from arbitrary pages.

5) Write a review-ready justification

• Summarize why each sensitive permission exists.
• Document what user action or product requirement triggers it.
• Keep the same explanation consistent across code review, store listing, and privacy narrative.

Strong defaults

• Treat host permissions as an explicit trust decision.
• Favor optional permissions and scoped enablement.
• Keep resource exposure and integration bridges small.
• Re-audit permissions whenever the feature set expands.

Anti-patterns

• Adding <all_urls> because it avoids up-front design work.
• Loading business logic from remote origins.
• Exposing large asset trees through web_accessible_resources.
• Letting store listing language drift away from actual permission usage.

Notes

• Primary references:
  • https://developer.chrome.com/docs/extensions/mv3/permission_warnings
  • https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview
  • https://developer.chrome.com/docs/extensions/mv3/manifest/web_accessible_resources
• Re-check current Chrome docs whenever a permission, CSP rule, or review policy question affects the implementation.