CSP不能硬拦截所有XSS，仅限制资源加载和脚本执行；HTML结构注入需靠服务端/客户端净化，而非CSP主动扫描；script-src 'self'不控制onerror等内联事件，除非禁用'unsafe-inline'。
加了 Content-Security-Policy 响应头，不代表XSS就被“硬拦截”了——它只对符合规则的资源加载和执行起作用，而HTML文档结构注入（比如用户输入被直接拼进DOM、innerHTML 写入、富文本解析后未净化渲染）本身不触发CSP检查，浏览器照常解析执行。真正能拦住这类攻击的，是CSP中对内联脚本和动态执行的严格限制，配合服务端/客户端的结构化处理。
为什么 script-src 'self' 拦不住 <img src=x onerror=alert(1)>
因为 onerror 是内联事件处理器，属于“内联脚本”的一种，而 script-src 'self' 只控制 <script src="..."> 这类外链脚本，对所有 onclick、onload、onerror 等属性一概不管。浏览器会直接拒绝执行，报错：Refused to execute inline event handler。但前提是你的策略里没写 'unsafe-inline'——一旦写了，这行就彻底失效。
-
script-src 'self'不影响 HTML 属性中的 JS 执行逻辑，只管<script>标签和eval()类调用 -
on*属性、javascript:伪协议、data:text/html等都归为“内联”，默认全禁 - 想让某段内联事件跑起来？不能加
'unsafe-inline'，得重构为addEventListener+ nonce 或 hash
HTML结构注入的硬拦截靠的是什么
不是靠CSP“主动扫描HTML标签”，而是靠它切断执行链路：只要恶意代码最终要变成可执行的JS（不管是通过 onerror、innerHTML 插入的 <script>，还是 eval() 解析字符串），CSP就能在执行前卡住。但前提是——这段代码真被浏览器当成JS去执行了。
- 如果用户输入被
document.write()或element.innerHTML = userHtml直接插入，且含<script>，CSP 会拦；但如果只是<img src=x onerror=...>，它拦的是执行，不是插入 -
innerHTML写入时，浏览器会解析并执行其中的内联事件和脚本，此时 CSP 生效；但若写入的是纯 HTML 结构（如<div></div>），CSP 不干预 - 真正“硬拦截 HTML 结构注入”的，其实是服务端或前端的 DOMPurify、sanitize-html 等库，它们在插入前就把危险标签/属性删掉，让CSP根本没机会出手
上线前必须确认的三个CSP执行前提
CSP不是设了就生效，它依赖底层基础设施和浏览器行为一致性。漏掉任意一项，策略形同虚设：
立即学习“前端免费学习笔记（深入）”；
- 必须用 HTTP 响应头设置
Content-Security-Policy，不能只靠<meta http-equiv="Content-Security-Policy">——后者不支持frame-ancestors、report-to，也无法生成动态nonce，Chrome 和 Safari 都会降级或静默忽略 - 所有子资源（iframe、Worker、fetch 返回的 HTML）不会继承父页 CSP，需各自设置；CMS 富文本输出、HTMX 渲染片段、SSR 模板插值结果，都得单独带响应头或做净化
-
Content-Security-Policy-Report-Only模式只能上报违规，不拦截；切到强制模式前，必须确认日志里没有误杀合法脚本（比如第三方统计、支付 SDK 的内联回调）
最易被忽略的一点：CSP 对 location.hash、URL 参数、localStorage 读取后直接 innerHTML 渲染的场景完全无感——这些路径绕过了资源加载阶段，只靠 CSP 拦不住。必须配合输入转义、DOM API 替代、以及可信上下文校验才能闭环。
