CSP不能替代XSS防御，而是限制已存在XSS的影响范围；必须禁用unsafe-inline/eval、配合输出编码、合理使用nonce与strict-dynamic，并确保script-src覆盖所有动态加载入口才能有效防护。
直接上结论：CSP在大规模Web应用中能拦住94%以上的XSS执行路径，但配置不当反而会阻断自身功能——关键不在“加不加”，而在script-src指令是否覆盖了所有动态加载入口、nonce是否随每次请求轮换、第三方SDK是否被漏掉。
为什么Content-Security-Policy响应头比<meta>标签更可靠
因为<meta>标签在HTML解析中途才生效，而内联脚本（比如首屏JS或服务端注入的初始化代码）可能早已执行完毕。HTTP响应头在浏览器收到第一个字节时就介入，能拦截包括重定向页面、iframe子页、甚至data: URI在内的全部资源加载。
- Apache/Nginx必须用
add_header或Header set，不能用set或echo等输出方式，否则头可能被覆盖或丢失 - Express/Next.js等框架需确保中间件顺序：CSP头必须在任何可能写入响应体的中间件之前挂载
-
Content-Security-Policy-Report-Only仅用于灰度期观察，上线前必须切为Content-Security-Policy，否则无实际防护力
script-src配置中最容易踩的三个坑
几乎所有线上CSP失效都源于script-src写法松动或遗漏。它不是“允许哪些CDN”，而是“只允许从哪些来源执行JS”——包括eval、onclick、new Function()、以及动态document.write生成的脚本。
- 绝对避免
'unsafe-inline'和'unsafe-eval'：哪怕只加一个，整个XSS防护就形同虚设 - Webpack/Vite构建产物若含内联
<script>（如SSR模板注入或热更新脚本），必须配nonce而非放宽策略；且nonce值必须每次HTTP响应唯一，不能复用或硬编码 - React/Vue等框架的
dangerouslySetInnerHTML或v-html内容若含JS执行逻辑（如javascript:void(0)），会被script-src拦截，需改用事件委托或预编译模板
如何让strict-dynamic真正生效而不破坏现代前端框架
strict-dynamic不是万能开关，它依赖“可信启动脚本”作为信任链起点。如果初始入口脚本没带nonce或哈希，后续所有动态创建的<script>都会被拒。
立即学习“前端免费学习笔记（深入）”；
- 必须配合
nonce使用：script-src 'nonce-abc123' 'strict-dynamic'，且首屏JS标签必须带nonce="abc123" - 禁止混用
'self'与'strict-dynamic'：script-src 'self' 'strict-dynamic'会导致浏览器忽略strict-dynamic，回退到源匹配 - Webpack 5+需开启
trustedTypes并配置__webpack_require__.nc等钩子，否则import()动态导入的chunk可能因缺少nonce被拦截
上线前必须验证的第三方和边缘场景
CSP策略一旦生效，所有违规加载都会静默失败，前端监控很难捕获——尤其当错误发生在iframe、web worker或第三方SDK内部时。
- 检查所有埋点SDK（如Sentry、神策、友盟）的JS域名是否列入
script-src，它们常通过document.write注入脚本，且域名可能动态变化 - 广告联盟、客服组件、地图API等常加载远程
<iframe>，需同步设置frame-src和connect-src，否则fetch上报或心跳请求会被拦 - 富文本编辑器（如Quill、Tiptap）插入的
<img onerror="...">属于内联事件，必须由script-src覆盖，或改用img-src+report-uri收集后人工清洗
最常被忽略的点是：CSP策略本身没有“继承性”。子域名、微前端子应用、甚至同一域名下不同路径的SPA路由，都需各自配置完整策略——不存在父域配置一次全站生效这回事。
