權限與 host 權限

​

權限策略

​

常見模式

​

由 background 驅動的功能

{
  "manifest_version": 3,
  "permissions": ["storage", "tabs", "scripting"],
  "host_permissions": ["https://example.com/*"]
}

​

可選能力

{
  "manifest_version": 3,
  "permissions": ["storage"],
  "optional_permissions": ["notifications"],
  "optional_host_permissions": ["https://api.example.com/*"]
}

​

實用規則

• 只在功能真正需要時才請求 API 權限。
• 把 host_permissions 限縮到能運作的最小起源集合。
• 對次要或進階功能優先採用可選權限。
• 每當你新增 background 動作、注入 content script 或呼叫遠端 API 時，重新審視權限。

​

依功能類型的權限設計

​

常見錯誤

• 當你只需要一兩個來源時，卻使用像 <all_urls> 這種寬鬆萬用字元。
• 把 host_permissions 混進其實可以用更窄、由使用者觸發的流程實現的功能。
• 忘記 content script、web-accessible resource，以及透過 chrome.scripting 的注入彼此的安全意涵不同。
• 在功能文件中只列出權限，卻沒解釋每個權限存在的原因。

​

審視清單

1. 列出每一個面向使用者的功能。
2. 把每個功能對應到實際需要的 API 與 host 權限。
3. 在可能的情況下，把非核心權限移到可選權限。
4. 移除舊實驗留下的陳舊權限。
5. 變更後重新測試安裝提示與瀏覽器商店預期。

​

後續步驟

• 在 manifest.json 中保持單一 manifest 的正確性。
• 在 Web-accessible resources 中檢視頁面存取。
• 在 Messaging 中驗證邊界處理。
• 透過安全檢查清單做一次發佈前審視。
• 在 Manifest V3 疑難排解中比較 permissions 與 host_permissions 的行為。