HTML中<meta>标签设置CSP效果有限，因其支持不全、生效滞后且不支持report-uri；无法防御DOM型XSS及含unsafe-inline/unsafe-eval的场景，须结合输入验证与输出编码。
HTML 中通过 <meta> 标签设置 CSP 策略，**能协同防御 XSS，但不能单独替代输入验证和输出编码**。它本质是浏览器端的最后一道防线，对已注入的脚本有强拦截能力，但对 DOM 型 XSS 或服务端未过滤的数据渲染仍存在盲区。
为什么标签的CSP在多数场景下效果有限
浏览器对 <meta http-equiv="Content-Security-Policy"> 的支持不如 HTTP 响应头完整：Chrome、Firefox 支持大部分指令，但 Safari 从 iOS 15.4+ 才开始支持 script-src 中的 'nonce-' 和 'hash-'；Edge 早期版本会忽略 report-uri。更关键的是：<meta> 在 HTML 解析中途才生效，若恶意脚本已在 <head> 前执行（比如通过 <svg onload="..."> 触发），CSP 来不及阻止。
常见错误现象：
- 本地开发用
<meta>测试正常，上线后 Safari 用户仍触发 XSS - 页面含第三方 SDK（如统计脚本）且使用内联
eval，<meta>无法覆盖其执行上下文 -
report-uri不上报 —— 因<meta>不支持该指令（仅 HTTP 头支持report-to或旧式report-uri）
script-src 'unsafe-inline' 是 CSP 失效的常见原因
很多前端项目为兼容旧逻辑，在 script-src 中写入 'unsafe-inline'，这直接废掉 CSP 对反射型/存储型 XSS 的核心防护能力。只要攻击者能控制任意一处 HTML 输出点（如评论、用户名、URL 参数回显），就能插入 <script>fetch('/steal?c='+document.cookie)</script> 并被执行。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
正确做法是用白名单机制替代：
- 对必须的内联脚本，改用
nonce：服务端每次响应生成唯一nonce-abc123，HTML 中写<script nonce="abc123">...</script>，CSP 配置为script-src 'self' 'nonce-abc123' - 对已知哈希值的内联脚本（如构建时确定），可用
'sha256-xxx'，但需注意 webpack 等工具需开启contenthash保证稳定性 - 完全避免
'unsafe-eval'—— 它让setTimeout("string")、new Function()等动态执行复活，等于打开后门
DOM型XSS中CSP的防护边界在哪
CSP 对纯客户端触发的 DOM 型 XSS（如 location.hash 解析后写入 innerHTML）作用微弱。因为这类攻击不加载外部资源，也不依赖 <script> 标签，而是靠 JS 自身操作 DOM 实现注入。此时 script-src 规则不触发，default-src 也管不到内存里的字符串拼接。
真实场景中的脆弱点：
-
document.write(location.search.slice(1))—— 即使 CSP 限制了所有脚本，这段代码本身合法，但会把 URL 参数原样写入并解析执行 -
el.innerHTML = '<img src=x onerror=alert(1)>'——onerror是内联事件处理器，被script-src禁止，但若 CSP 漏配了default-src 'unsafe-inline'或未设script-src，就可能执行 - 使用
jQuery.html()或 Vue 的v-html渲染用户数据，且未做转义 —— CSP 无法阻止这种运行时行为
CSP 不是银弹。它最有效的场景是阻断「外部脚本加载」和「未经许可的内联脚本执行」，但对服务端未过滤的输出、客户端不当的 DOM 操作、以及浏览器解析顺序导致的竞态，都无能为力。真正健壮的 XSS 防御，必须把 CSP 当作策略层，和输入校验、上下文敏感的输出编码、可信类型（Trusted Types）一起落地。
