先确认插件的攻击面
一个插件至少包含 manifest、background service worker、content script、popup/options 页面和外部资源。 审计第一步是画出数据流：页面数据从哪里来，经过哪些脚本，写入哪里，又通过什么接口发出去。 只有把数据流画清楚，后面的权限和风险判断才不会变成猜测。
经验规则：凡是能读取页面、能访问 cookie、能跨域请求、能长期保存数据的模块，都要当作高风险边界处理。
权限越少，问题越少
Manifest V3 的权限应尽量拆细。能用 activeTab 就不要默认申请所有站点；能限定 host_permissions 就不要写 <all_urls>；只在用户触发功能时注入脚本，而不是打开页面就长期运行。权限审计不只是为了上架审核， 也是为了降低插件被利用后的影响范围。
- 检查 permissions 和 host_permissions 是否与功能一一对应。
- 检查是否加载远程脚本、远程配置或不受控的第三方资源。
- 检查 storage 中是否保存 token、手机号、聊天内容或业务线索。
- 检查 popup 和 options 页面是否把敏感数据直接写入 DOM。
消息通信必须做身份和结构校验
很多插件的真实风险出在消息通道。content script、页面脚本、background 之间通过 postMessage 或 chrome.runtime.sendMessage 传数据时，必须校验来源、动作类型和字段结构。不要让页面随便构造一个 action， 就能触发后台请求、读写存储或执行批量操作。
message = {
action: "EXPORT_LOGS",
requestId: "uuid",
payload: { range: "today" }
}
validate(action in allowedActions)
validate(sender.tab.url in allowedHosts)
validate(payload schema)可直接复用的审计清单
权限：是否存在无必要的 all_urls、tabs、cookies、webRequest。
注入：是否避免 innerHTML 拼接不可信内容，是否优先使用 textContent。
消息：是否校验 sender、origin、action 白名单和 payload schema。
存储：是否对敏感数据设置过期策略，是否避免明文保存凭证。
网络：是否固定 API 域名，是否处理请求失败、重试和限流。
日志：是否避免把 token、完整手机号、聊天正文写入调试日志。
最后把清单变成自动化检查：manifest 用脚本扫描权限，源码用规则搜索危险 API，运行时用测试账号验证消息边界。 插件越复杂，越需要把安全审计内置到发布流程，而不是上线前临时看一眼。