最小权限原则

前两章讲了权限是什么、怎么按需申请。这一章讲”度”——到底该要多少。最小权限原则（least privilege）一句话概括：只申请真正用得上的权限，能窄不宽，能晚要不当初全要。 这既是安全常识，也是 MV3 时代商店审核的核心口径。

25-1 什么是最小权限原则

最小权限原则要求每个扩展只持有完成功能所必需的最低权限。多要一项，就多一分风险、多一分解释成本。Chrome 官方安全文档把这一点放在显眼位置：标题就叫”Request minimal permissions”（请求最少的权限）。

落到清单上，它表现为几个可操作的动作：能不申请的就不申请；能用窄范围就别用宽范围；能运行时再要的就别安装时全要。第 23 章的”权限两条轴”在这里派上用场——你每加一项 permissions 或 host_permissions，都该能回答”这个功能离了它能不能做”。

25-2 用 activeTab 代替宿主权限

最典型的一招，是用 activeTab 替代 host_permissions。很多扩展只是”用户点一下才动当前页”，比如染红背景、划词标注、自动填表。这种情况根本不需要常驻的宿主权限。

把 activeTab + scripting 写进主权限，用户点工具栏按钮时临时获得当前页访问权，动作结束即收回。对比在 host_permissions 里写 <all_urls>，前者安装零警告，后者吓退一片用户。

{
  "name": "Very Secure Extension",
  "manifest_version": 3,
  "permissions": ["activeTab"]
}

官方隐私文档也专门列了”activeTab”一节，把它当作减少所需权限的首选手段。凡是”操作当前页”的需求，先想 activeTab 能不能覆盖，再考虑宿主权限。

25-3 把进阶权限交给 optional 系列

第 24 章讲的 optional_permissions / optional_host_permissions，是最小权限的第二个抓手。核心功能走主权限，那些”偶尔才用”的进阶能力，推迟到用户触发时再申请。

官方隐私文档给的示例就是这个思路：

{
  "name": "Very Secure Extension",
  "manifest_version": 3,
  "optional_permissions": ["tabs"],
  "optional_host_permissions": ["https://www.google.com/"]
}

这样安装时不显示任何相关警告，用户用到对应功能时才弹一次窗。既保住了核心体验的干净安装，又在不打扰的前提下拿到了所需能力。

25-4 收窄宿主范围，别写 <all_urls>

当你确实需要宿主权限时，务必把它收窄到真正用到的域名。能写 https://api.example.com/* 就别写 https://*/*，更别写 <all_urls>。

官方安全文档的”跨源 fetch”示例，特意把宿主范围缩到最小：

{
  "name": "Very Secure Extension",
  "version": "1.0",
  "manifest_version": 3,
  "host_permissions": [
    "https://developer.chrome.com/*",
    "https://*.google.com/*"
  ]
}

它只列了实际要通信的两个站，而不是全网通配。收窄的好处有三：安装警告更少、商店审核更顺、用户数据暴露面更小。每多一个通配域，就意味着扩展对该域拥有读内容、发请求的能力，风险随之扩大。

25-5 限制清单字段的暴露面

最小权限不只看 permissions 数组，整个清单都是”攻击面”。官方安全文档提醒：要限制清单里那些会放权的字段，只开必要的。

• externally_connectable：决定哪些外部网页/扩展能和你通信。默认不写最安全；真要写，ids 和 matches 都收紧到明确对象，别用通配放给全网。
• web_accessible_resources：决定哪些资源能被网页访问。只列确实要暴露给页面的资源，并用 matches 限定来源站。

{
  "name": "Super Safe Extension",
  "manifest_version": 3,
  "externally_connectable": {
    "ids": ["iamafriendlyextensionhereisdatas"],
    "matches": ["https://developer.chrome.com/*"],
    "accepts_tls_channel_id": false
  }
}

这些字段和权限是同一件事的不同侧面：都是”你向外界让渡的能力”。能不给就不给，能给具体对象就不给通配。

25-6 商店审核关注哪些点

讲完做法，说审核。商店（Chrome Web Store 等）审核扩展时，会重点看权限与功能的匹配度：

• 宿主权限是否过宽：大面积、通配的 host_permissions（尤其 <all_urls>）会触发重点审查。你要能在功能说明里讲清”为什么需要访问这些站”。
• 敏感权限是否必要：history、tabs、bookmarks、cookies、downloads、declarativeNetRequest 等都会被多盯一眼。不是不能用，而是得和功能直接对应。
• 权限与隐私政策/功能描述是否一致：申请的权限要在说明文档里有交代，不能”要了却不解释”。
• 是否用 optional 规避警告：审核员看的是实际行为。把本该主权限的藏进 optional 来骗过警告，反而可能被判定为误导。

25-7 过度申请的三重风险

最后把”过度申请”的代价摊开，你就知道为什么要克制：

1. 用户信任下降：安装警告一长串，普通用户直接退出安装。权限越多，用户越觉得”这东西想偷我数据”。
2. 过审更难：敏感/过宽权限会拉长审核、增加被打回的概率。打回意味着上线推迟、版本迭代变慢。
3. 攻击面变大：权限是能力，也是风险。扩展一旦被攻破（或某个依赖被污染），它持有的权限越多，攻击者能造成的破坏越大。最小权限等于把”爆炸半径”压到最小。

还有隐私层面的细节：比如处理无痕（incognito）标签页时，不该把其数据写进普通存储。官方隐私示例就检查了 tab.incognito，无痕下直接跳过保存：

function saveTabData(tab) {
  if (tab.incognito) {
    return;
  } else {
    chrome.storage.local.set({ data: tab.url });
  }
}

权限最小化是安全与过审的第一道门。把这一章和前两张连起来看：权限模型 = 分清两类权限（23）→ 按需运行时申请（24）→ 能少要就少要（25）。下一模块进入用户界面组件，我们会发现 UI 能力同样要按”最小必要”的精神来取用。