启用CSP后Web应用收到莫名Google Fonts(Open Sans)拦截报告的排查求助

这情况我之前排查过类似的，结合踩过的坑和经验，给你梳理几个最可能的原因，帮你确认问题是否出自你方：

最常见：浏览器扩展/用户脚本注入 #

这绝对是排在第一位的原因！很多广告拦截、页面美化、字体替换类的Chrome扩展，会偷偷在加载的页面里注入请求Google Fonts（尤其是Open Sans这种常用字体）的代码。比如有些扩展会强制把所有页面的字体换成Open Sans，完全不管原页面用的是什么字体。

这类请求是用户端本地触发的，和你的应用代码半毛钱关系都没有，只会在安装了该扩展的用户浏览器里出现——这也完美匹配你说的“仅每日特定时段出现”：大概率是某个固定用户在这个时间段访问你的应用，而他的浏览器装了这类扩展。

用户本地浏览器自定义设置 #

有些用户会手动修改Chrome的字体配置，或者通过chrome://flags里的实验性选项强制系统使用特定字体。当本地没有该字体文件时，浏览器可能会尝试从Google Fonts拉取资源。不过这种情况相对少见，而且通常用户自己会知道改了设置。

第三方嵌入内容（需再确认） #

虽然你说已经排查了源码和依赖，但如果你的应用里嵌入了第三方内容（比如广告组件、统计脚本、评论区等），极少数第三方服务会偷偷加载Google Fonts。不过你已经自查过依赖，这个可能性很低，但可以再快速扫一遍这些外部嵌入资源的请求日志，确认有没有隐藏的字体请求。

罕见情况：Chrome内置功能/实验特性 #

极少数情况下，Chrome的一些无障碍功能、实验性特性可能会触发这类字体请求，但这种情况非常少见，而且CSP报告通常会带有更明确的上下文信息，和你描述的“无有效来源信息”不太匹配。

如何确认问题不在你方？ #

• 用Chrome的无痕模式访问你的应用：无痕模式默认禁用所有扩展，如果此时没有产生CSP拦截报告，基本实锤是用户端扩展导致的。
• 用Chrome DevTools的Network面板，过滤font类型请求：自己正常访问应用时，看看有没有Google Fonts的请求，只要你这边完全看不到，就说明你的代码确实没引入相关资源。
• 再仔细核对CSP报告里的document-uri字段：哪怕信息有限，也能确认请求发起的页面路径，再检查该页面的源码，确保没有遗漏的字体引用。

从你的描述来看，“仅特定时段出现、自身代码无相关内容”，大概率是用户端的浏览器扩展搞的鬼，基本可以排除是你方应用的问题。

内容的提问来源于stack exchange，提问作者Jonathan