CSP是否真正生效需以HTTP响应头为准，meta标签仅降级兼容且不支持report-uri、nonce等关键指令；应通过开发者工具Network面板检查Response Headers中是否存在Content-Security-Policy字段，并触发违规操作验证控制台报错及上报行为。
怎么判断CSP是否真正生效
光在HTML里写<meta http-equiv="Content-Security-Policy">不等于防护落地。浏览器只认HTTP响应头里的Content-Security-Policy，<meta>标签仅作降级兼容，且不支持report-uri、script-src中的nonce等关键指令。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具的Network面板，选中HTML请求，查看Response Headers里是否有
Content-Security-Policy字段；没有就说明配置没走通 - 故意触发违规（比如在控制台执行
eval("alert(1)")），看Console是否报Refused to evaluate a string as JavaScript类错误，同时检查是否向report-uri地址发出上报请求 - 避免混用
default-src 'self'和宽松的script-src *——后者会覆盖前者，实际等同于放行所有脚本
script-src怎么配才不被绕过
script-src是CSP中最容易被误配的核心指令。常见错误是只加CDN域名却忘了允许内联脚本的nonce或hash，结果导致页面JS直接报错白屏。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 禁用
unsafe-inline和unsafe-eval是底线，但必须配套提供替代方案：对每个<script>标签加nonce属性，并确保服务端每次渲染都生成新值 - 若用
hash方式，需对JS内容做SHA256并Base64编码，例如sha256-X67Gz...；注意空格、换行、BOM都会影响哈希值 - 不要把
'unsafe-hashes'当救命稻草——它只对内联事件处理器（如onclick）有效，且现代浏览器支持度差，别依赖
富文本场景下CSP与DOMPurify怎么协同
用户提交的富文本内容如果直接用innerHTML插入，CSP拦不住，因为这是DOM操作而非资源加载。这时候单靠CSP无效，必须配合净化逻辑。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
DOMPurify.sanitize()返回的是字符串，不是DOM节点，务必再用textContent或安全API（如element.setHTML()）插入，而不是拼接后innerHTML = ... - 配置
DOMPurify时显式关闭ALLOWED_TAGS和ALLOWED_ATTR白名单，禁用script、onerror、javascript:等全部危险项 - 即使用了
DOMPurify，也要在CSP里加object-src 'none'和base-uri 'self'，防止被绕过注入<base href="javascript:">类攻击
审计时最容易漏掉的CSP副作用
CSP不是开箱即用的安全开关，它会直接影响前端行为，而很多团队只测功能，不测限制后的异常路径。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 检查所有使用
new Function()、setTimeout(string)、setInterval(string)的地方——这些都会被unsafe-eval拦截，必须改用函数引用形式 - 确认Google Analytics、Sentry等监控SDK是否在
script-src白名单里，否则错误日志根本不上报，你连漏洞都发现不了 - 移动端WebView常忽略CSP响应头，尤其Android 4.x–6.x；若支持旧系统，必须在
<meta>里补一份简化版策略，并测试其实际拦截效果
