前端 CSP 上线怎么做：从报告模式到正式拦截的加固清单

给网站接入内容安全策略（CSP）的时候，最容易踩坑的操作就是随便抄一段严格规则直接全量上线，页面里的脚本、样式、图片、字体、接口请求和各类第三方资源都可能被新策略拦截，最终表现为白屏、登录失败、数据加载异常。更稳妥的落地路径是先梳理清楚实际用到的全部资源来源，通过报告模式观察策略影响，再按资源类型逐步收紧规则，最后切到正式拦截完成全量回归验证。

生产目标：限制来源，不中断业务

CSP 的作用不是让页面完全加载不了外部资源，而是把所有允许加载的来源明确列出来。MDN 文档说明，资源获取指令可以分别约束脚本、样式、图片、字体和网络连接；没有单独指定的资源类型，会自动回退到 default-src。因此上线的首要目标是先摸清楚页面到底依赖了哪些外部来源，而不是刚上手就追求最短最严的规则。

环境准备：先做资源来源盘点

在测试或预发环境打开浏览器开发者工具，逐一梳理页面加载的脚本、样式、图片、字体、接口、WebSocket 和埋点请求。要特别注意第三方登录、支付、地图、客服、监控和 CDN，它们往往不是主站域名，却是业务运行的必需来源。每个梳理出来的来源都要明确对应的用途、维护负责人，确认是否还在正常使用。

安全配置：先观察，再收紧

初次接入建议先使用仅上报的策略，浏览器只会记录拦截行为而不改动页面现有运行逻辑，你可以直观看到哪些资源会被规则命中。上报回来的来源不要直接全部加入白名单，先逐一核对它是否为当前业务必需、域名是否可信、有没有机会迁到自家可控域名下。确认没问题的来源，再把规则拆分到对应的资源类型中，不要用宽泛的通配来源一次性放开所有权限。

MDN 对连接来源的说明指出，普通网络请求、长连接、事件流等都受连接来源规则约束，这也是很多站点第一次启用 CSP 后普通接口能正常跑，实时消息却直接断连的常见原因。按资源粒度拆分配置和多环境验证的优先级同样高。

权限边界：不要用宽松规则掩盖问题

遇到资源被阻断时，最省事的做法看似是直接放宽规则，但这么做会直接抵消CSP的加固价值。优先替换不必要的内联逻辑、清理早就下线的旧第三方依赖、把静态文件迁到可控来源下，再为确实有必要保留的资源添加最小范围的权限规则。脚本相关规则要格外谨慎，MDN也明确提示，允许所有内联脚本权限会带来很高的安全风险，应该优先采用更精准的替代方案。

发布检查：看控制台，也看真实业务路径

1. 在预发环境跑通登录、搜索、提交表单、上传、支付或核心转化路径。
2. 检查浏览器控制台是否仍有 CSP 违反记录。
3. 确认接口、实时连接、图片、字体和第三方嵌入内容运行全部符合预期。
4. 灰度到小流量后观察错误率、前端异常和用户反馈。
5. 保留回退开关和变更记录，确认稳定后再逐步扩大覆盖范围。

常见问题

为什么只设置 default-src 后页面会出问题？

它会作为多种资源的默认回退规则。若页面依赖了不同域名的接口、图片或字体，这些来源没有被单独明确允许，就可能被浏览器直接拦截。

报告模式是不是不用处理风险？

肯定不是。它适合用来梳理依赖、验证候选规则，不会实际执行拦截逻辑。完成所有依赖盘点和全量回归后，仍要按计划切换到正式执行模式。

遇到被阻断的第三方资源应该直接放行吗？

先确认该资源确实是当前业务必需、来源可信且没有可替代方案。能下线的旧依赖直接清理，确需保留时才以最小权限粒度加入对应资源类型的规则。

走完资源盘点、报告观察、最小权限配置、灰度验收四步，CSP 就不会是容易误伤业务的随便抄来的规则，而是可长期维护的前端安全加固边界。