为何CSP报告出现fonts.gstatic.com，但站点代码未引入该外部字体？

先明确你的CSP违规报告信息：

"csp-report": {
    "document-uri": "https://www.example.com/",
    "referrer": "",
    "violated-directive": "font-src",
    "effective-directive": "font-src",
    "disposition": "enforce",
    "blocked-uri": "https://fonts.gstatic.com/s/mulish/v12/1Ptvg83HX_SGhgqk0AotcqA.woff2",
    "status-code": 200,
    "script-sample": ""
}

除了你推测的浏览器扩展注入字体外，还有以下几种可能的原因：

• 第三方资源隐式引入：你页面中加载的第三方脚本（比如广告、统计工具、第三方UI组件库）可能在内部通过@font-face或其他方式引入了Mulish字体。这类资源的字体引用不会直接出现在你的HTML/CSS/JS源码中，而是由第三方代码动态加载。
• 浏览器内置行为触发：部分浏览器的无障碍功能、字体优化或替换机制，可能会自动尝试加载Web字体来替换系统默认字体。比如某些浏览器的"字体平滑"或"自定义字体"功能，会在后台请求外部字体资源。
• 缓存或CDN残留内容：如果你的网站曾经使用过Mulish字体，浏览器本地缓存或CDN边缘节点可能还保留了旧的页面资源引用。部分用户访问时加载了缓存中的旧内容，从而触发CSP违规。
• 动态样式注入：虽然你检查了静态CSS文件，但可能存在内联的@font-face规则，或者页面加载后通过JavaScript动态创建了样式规则引入该字体。这类注入可能来自你依赖的某个小众脚本，或者之前遗留的未清理代码。
• 同源iframe的跨资源引用：如果你的页面包含同源的iframe，且该iframe中引入了Mulish字体，主页面的CSP策略会默认应用到iframe（未单独配置CSP的情况下），导致主页面的报告中出现该违规条目。
• 用户端临时操作触发：用户使用浏览器开发者工具调试页面时，可能手动添加了字体引用代码，或者安装了临时的用户脚本注入了字体，这类情况属于临时触发，不会大规模出现。

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