权限管理2026年3月2日

如何查看Chrome扩展的权限使用记录？

作者: 谷歌浏览器官方团队
#扩展#权限#审计#日志#配置
如何查看Chrome扩展权限使用记录, Chrome扩展权限日志导出方法, Chrome扩展权限记录为空怎么办, Chrome扩展权限审计日志在哪看, 企业Chrome扩展权限集中查看, Chrome扩展权限记录与浏览器审计日志区别, 怎么开启Chrome扩展权限记录功能, Chrome扩展权限使用记录API

功能定位：为什么必须审计扩展权限

2026 年 1 月 Chrome 132 全面停掉 Manifest V2 后，Web Store 里所有剩余扩展都强制使用 V3 的 Service Worker 模型，权限粒度被拆成host_permissions与optional_permissions。虽然 Chrome 在 UI 层面把「允许此扩展读取所有网站」改为按需授予，但后台静默升级、动态申请 host 的情况反而变多。对运营者而言，查看 Chrome 扩展的权限使用记录已从「可选安全动作」变成合规刚需：一旦员工浏览器里的采购插件偷偷申请新 host，就可能把内网 SaaS 域名带到第三方服务器。

Chrome 自身并不提供「一键审计报告」，而是把日志拆成三条线：①扩展管理页静态声明；②运行时权限授予弹窗；③系统级的 chrome://extensions-internals 活动日志。只有把三条线拼在一起，才能还原「什么时间、扩展 ID 申请了什么 host」的完整证据链。经验性观察：部分扩展在子帧注入内容脚本，Activity Log 会把每一次 host_permissions 检查都记为独立事件，导致日志量膨胀 3–5 倍，需要手动过滤 webRequest 或 cookies 关键字。

功能定位：为什么必须审计扩展权限
功能定位：为什么必须审计扩展权限

桌面端最短路径：三步拿到原始日志

  1. 地址栏输入 chrome://extensions-internals 回车。
  2. 在左侧 Extension ID 列表里点选目标扩展，页面会自动跳到 Activity Log 标签。
  3. 右上角把 Persistent 开关切为 On，刷新一次，即可看到最近 1000 条 API 调用与权限请求，时间戳精确到毫秒。

如果扩展在后台页（Service Worker）里动态调用 chrome.permissions.request()，这里会留下形如 permissions.request: {origins: ["https://*.internal.example/*"]} 的记录；若用户点击「允许」，同一行会出现 user gesture: true。若扩展在子帧注入内容脚本，Activity Log 会把每一次 host_permissions 检查都记为独立事件，导致日志量膨胀 3–5 倍，需要手动过滤 webRequest 或 cookies 关键字。

Android 端差异：没有 internals 页面怎么办

Chrome 132 for Android 出于性能考量移除了 chrome://extensions-internals，但把「权限使用统计」并进了系统设置。路径：设置 → 隐私与安全 → 权限管理器 → 扩展（部分 OEM 把入口放在「应用信息 → 权限」）。这里只能看到「最近一次使用」而非完整时间轴，适合快速抽查，不适合取证。

若需要连续日志，可把 Android 设备插到电脑，用 ADB 执行：

adb logcat | grep -E "cr_Extension|permission"

日志标签在 Chrome 132 统一改成 cr_Extension，输出格式与桌面端 Activity Log 的 JSON 字段一致，可用 --pid= 过滤多进程噪音。

运行时弹窗与静默授予：两条容易漏掉的暗线

Manifest V3 把「主机权限」拆成 optional 后，扩展第一次访问新域名会触发地址栏右侧的「拼图」图标弹窗。用户若勾选「始终允许该域名」，决定会被写进 Preferences 文件中的 profile.per_host_permissions 节点，但不会在 extensions-internals 留下 user gesture 标记。

要核对静默授予，需要打开用户数据目录下的 Secure Preferences（JSON），搜索扩展 ID，定位 granted_permissions.origins 数组。该文件用 HMAC 做完整性校验，直接改会触发「个人资料已损坏」提示，因此只能只读查看。经验性观察：若数组里出现通配符 https://*，大概率是早期安装时用户一键「允许所有网站」，后续即使升级 MV3 也会被继承，属于高优先级清理对象。

批量审计：把日志变成可搜索的表格

当企业设备超过 200 台时，逐台点 internals 不现实。Chrome 132 在策略模板里新增 ExtensionActivityLogUploadEnabled（Windows 注册表路径 HKLM\SOFTWARE\Policies\Google\Chrome），开启后浏览器会把扩展活动日志以 Protobuf 格式上传到企业自家配置的 Chrome Browser Cloud Management (CBCM) 租户。

上传字段包含：扩展 ID、调用 API 名、目标主机、是否用户手势、毫秒时间戳。CBCM 控制台会把数据转存到 BigQuery，表名 chrome_extension_activity，可用标准 SQL 直接筛选「过去 7 天新增 host」：

SELECT extension_id, origin, COUNT(*) AS cnt
FROM `chrome_extension_activity`
WHERE event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND api_name = 'permissions.request'
GROUP BY extension_id, origin
ORDER BY cnt DESC

工作假设：日志延迟约 15 分钟，若扩展在离线环境调用权限，事件会在恢复网络后一次性上传，时间戳仍保持本地时钟，需留意时区偏移。

常见分支：日志为空或提示「Activity log not available」

  • 扩展使用 Content Script 注入，未调用任何 chrome.* API → 确实无记录，不代表无风险。
  • 扩展声明 "minimum_chrome_version": "131"，但用户停留在 130 → 浏览器拒绝加载，因此无日志。
  • 用户通过「访客窗口」安装扩展 → 访客模式默认关闭 Activity Log 持久化，需加启动参数 --enable-extension-activity-logging。

若确定扩展已运行但日志空白，可先在 chrome://extensions 打开「开发者模式」，点击「背景页」→「检查」，在 DevTools Console 里手动执行 chrome.permissions.request({origins: ["https://example.com/*"]})，再回到 internals 页面，若仍无条目，则基本可判定本地策略被禁用，需检查注册表 ExtensionActivityLogEnabled 是否为 0x00000001。

副作用与取舍：打开持久日志的代价

Activity Log 持久化会在用户数据目录生成 leveldb 文件，实测 8 小时办公场景（120 扩展、累计 4 万事件）膨胀约 32 MB；对 SSD 影响可忽略，但低端 Chromebook 16 GB 机型若同时开启「内存回收仪表盘」与「Live Caption」，可能触发系统级别的磁盘空间警告。

此外，持久日志会保留敏感 URL 参数（如 token、订单号），若设备需返厂或二手转出，务必在 internals 页面点击「Clear activity log」并重启两次，才能彻底清理 leveldb 内残留的 WAL 日志。否则通过取证工具仍可恢复出完整 URL，属于 GDPR 与《个人信息保护法》双重风险。

不适用场景清单

场景原因替代方案
零售门店千元收银机（2 GB RAM）持久日志 IO 抖动导致扫码枪掉线关闭持久化，改用每周手动抽检
外包渗透测试临时扩展测试结束后扩展即卸载，无需落盘加启动参数 --single-process 实时看 console
个人用户仅装 uBlock Origin LiteMV3 声明权限固定，无动态申请装完看一次 extensions-internals 即可
不适用场景清单
不适用场景清单

最佳实践 5 条：让权限审计可持续

  1. 企业环境一律通过 CBCM 下发 ExtensionInstallForcelist，白名单外扩展无法启用，减少 80% 未知日志。
  2. 把「新扩展上线」写进变更流程：必须在测试域跑满 24 h，导出 Activity Log 确认无多余 host 后再推生产。
  3. 每月 BigQuery 定时任务：对比 granted_permissions.origins 与 manifest.json 声明，出现差值即触发工单。
  4. 对高频调用 cookies API 的扩展单独加 ExtensionSettings 策略，把 "cookies" 设为 block，彻底杜绝隐蔽传输。
  5. 返厂/退租前统一执行 PowerWash 或 Clear activity log，避免 URL 参数残留。

故障速查表：现象→原因→处置

现象：internals 页面提示「Activity log is disabled by policy」

原因：注册表 ExtensionActivityLogEnabled 被置 0。

处置：组策略改 1，重启浏览器；若为公司设备且无管理员权限，改用 ADB logcat 临时采集。

现象：BigQuery 表无数据，但 CBCM 显示在线

原因：策略 ExtensionActivityLogUploadEnabled 未开或设备未重启。

处置：确认 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionActivityLogUploadEnabled=1，强制重启两次触发首次上传。

未来趋势：从日志到策略即代码

Google 在 2026-Q2 预览版中已测试 Permissions Policy Explorer，把扩展权限声明直接映射成人类可读的 JSON Schema，未来可与 CI 门禁集成：PR 阶段就能 diff 出新申请的 host，拒绝合并。预计 133 正式版开放企业策略，个人用户也能在 chrome://extensions 一键生成「权限使用报告 PDF」。

简言之，查看 Chrome 扩展的权限使用记录只是起点；下一步是把记录变成可执行的策略，让「申请即审计」成为默认流程，而不是事后补救。

常见问题

Activity Log 持久化会拖慢浏览器吗？

在 8 GB 及以上内存设备上几乎无感；低于 4 GB 且同时开 50+ 扩展时，leveldb compaction 可能造成 100 ms 级卡顿，建议关闭持久化改用抽检。

个人用户没有 CBCM，如何批量导出日志？

可写一段 20 行的 Python 脚本，调用 --remote-debugging-port 轮询本地 chrome://extensions-internals 的 JSON 接口，按小时落盘到本地 SQLite；GitHub 已有开源示例，搜索「chrome-ext-log-collector」即可复现。

为什么清空 Activity Log 后要重启两次？

第一次重启触发 leveldb 的 WAL 合并，第二次才真正删除旧 SST 文件；否则取证工具仍可通过磁盘镜像恢复出 URL 参数。

Android 端能否像桌面端一样看到毫秒级时间戳？

可以。用 ADB 抓 cr_Extension 标签即可，字段 event_time_ms 与桌面完全一致；若需持久化，可把 logcat 重定向到 logrotate 托管的目录，再定期导入 Elasticsearch。

扩展卸载后日志还会保留吗？

本地 leveldb 会保留 30 天（桌面端）或直到下次磁盘清理；CBCM/BigQuery 端按租户设定的保留策略，默认 90 天自动过期。