HTML中CSP的<meta>标签无法构成硬性防护，因其不支持report-uri、report-to、frame-ancestors等关键指令，无法拦截document.write()或动态eval()触发的内联执行，且被HTTP响应头优先覆盖；生产环境必须使用服务端Content-Security-Policy响应头，<meta>仅适用于无后端的静态托管场景（如GitHub Pages）。
怎么在HTML里写CSP meta标签才不被绕过
直接写<meta http-equiv="Content-Security-Policy" content="default-src 'self'">看似省事，但实际无效或弱效——浏览器对meta标签的CSP支持有限制：不支持report-uri、report-to，也不支持worker-src、manifest-src等指令；更关键的是，meta无法覆盖document.write()、动态eval()触发的内联执行路径。生产环境必须用HTTP响应头Content-Security-Policy，meta仅适合原型验证或静态托管场景（如GitHub Pages无后端时临时启用）。
audit时重点查哪几类script-src配置错误
代码审计中，以下script-src写法几乎必然引入XSS风险：
-
script-src 'unsafe-inline'：放行所有<script>alert(1)</script>和onclick="..."，等于关掉CSP核心防护 -
script-src 'self' 'unsafe-eval'：允许eval()、Function()、setTimeout("...")，攻击者可拼接字符串执行任意代码 -
script-src *或script-src data:：开放全部域或data URI，恶意base64脚本可直接注入 - 漏写
script-src，只设default-src 'self'：此时script-src继承default-src，但default-src不控制nonce或hash匹配逻辑，导致合法内联脚本也被拦
为什么base-uri、form-action、frame-ancestors必须显式声明
这些指令默认不继承default-src，且浏览器宽松处理——不配就等于“全开”：
-
base-uri未设 → 攻击者可插入<base href="https://evil.com">，让所有相对路径资源（如./js/app.js）加载恶意脚本 -
form-action未设 → 表单可提交到任意第三方地址，CSRF成功率大幅提升 -
frame-ancestors未设 → 页面可被任意域名<iframe>嵌入，点击劫持（Clickjacking）无防护 -
object-src 'none'漏配 → Flash/Java插件仍可加载，老系统上存在远程代码执行链
上线前怎么验证动态HTML是否被CSP覆盖
富文本渲染、模板引擎插值、SPA路由切换生成的DOM，极易产生未声明的内联脚本或javascript:链接，审计时需人工+工具双验证：
立即学习“前端免费学习笔记（深入）”；
- 打开DevTools → Console，执行
document.querySelectorAll('script:not([src]):not([nonce]):not([integrity])')，检查是否存在无nonce也无integrity的内联<script> - 检查所有
innerHTML = ...赋值点，确认右侧变量是否经DOMPurify.sanitize()处理，且未包含onerror=、javascript:等危险模式 - 用
Content-Security-Policy-Report-Only头部署灰度环境，抓取/csp-report日志，重点关注violated-directive: script-src和blocked-uri: inline条目 - 特别注意Vue/React组件中
v-html或dangerouslySetInnerHTML调用点，这些是CSP盲区高发位置
真正难的不是写一条CSP规则，而是让每段动态生成的HTML都落在策略覆盖范围内——它要求前端工程必须把安全约束嵌入到模板、组件、富文本处理全流程，而不是靠最后加个响应头了事。
