必须通过http响应头设置csp，禁用unsafe-inline和unsafe-eval，采用default-src 'none'并显式放行资源，配合nonce机制与report-to上报，才能有效防御xss。
直接用 HTTP 响应头配 CSP，别用 <meta>
浏览器对 <meta http-equiv="Content-Security-Policy"> 的支持不完整：Safari 直到 iOS 15.4+ 才支持 nonce- 和哈希值，report-uri 根本不生效；更关键的是，<meta> 在 HTML 解析中途才加载，而恶意脚本（比如 <svg onload="alert(1)"></svg>）可能早已执行。生产环境必须走服务端响应头：Content-Security-Policy，不能降级为标签。
script-src 必须禁掉 'unsafe-inline' 和 'unsafe-eval'
这两个值一开，等于把 CSP 对 XSS 的防护能力归零。只要攻击者能控制任意一处 HTML 输出（用户名、URL 参数、评论），就能插入 <script>fetch('/steal?c='+document.cookie)</script> 并成功执行。正确做法是：
- 默认只允许同源脚本：
script-src 'self'—— 自动拦截所有内联<script></script>和onclick等属性 - 确需少量内联脚本时，用 nonce：
script-src 'self' 'nonce-AbC123'，并在对应<script nonce="AbC123"></script>中显式声明 - 绝对不用
'unsafe-eval'—— 它会让setTimeout("string")、new Function()复活，给攻击者留后门
沙箱不是 CSP，但 sandbox 属性能补 DOM 型 XSS 的盲区
CSP 对纯客户端触发的 DOM 型 XSS（如 el.innerHTML = location.hash）基本无效，因为它不拦截 JS 内存里的字符串拼接。这时 <iframe sandbox="..."></iframe> 是唯一能真正隔离执行环境的手段：
- 加
sandbox=""后，iframe 默认禁用脚本、表单提交、插件、弹窗等所有能力 - 按需放开：比如只允许同源脚本执行，写
sandbox="allow-scripts allow-same-origin"（注意：二者同时存在会削弱隔离性） - 不要单独依赖 sandbox 防 XSS —— 它只作用于 iframe 内容，主页面仍需严格 CSP + 输入转义
default-src 'none' + 显式放行，比只设 script-src 更可靠
很多人只配 script-src 'self'，以为万事大吉，结果 img-src 或 connect-src 缺失导致浏览器回退到宽松策略。更稳妥的做法是从零开始构建：
- 先写
default-src 'none'，关闭所有资源默认加载 - 再逐项放开必需项：
script-src 'self' 'nonce-xxx'、style-src 'self' 'nonce-xxx'、img-src 'self' data:、connect-src 'self'、form-action 'self' - 加上
object-src 'none'和base-uri 'none'，堵住 Flash、Java 插件和 base 标签劫持路径 - 务必启用
report-to（不是report-uri，后者已过时），把违规行为实时上报，否则你根本不知道哪段代码在绕过策略
真正难的不是写对那几行指令，而是让每个动态生成的 HTML 响应都带匹配的 nonce，且前端 JS 不再用 innerHTML 拼接用户数据 —— 这两点漏掉任何一项，CSP 就形同虚设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
