script-src 'self' 不能防xss，因默认放行内联脚本、eval()和事件处理器；需显式禁用'unsafe-inline'，并配合nonce或hash机制，同时配置base-uri、form-action、frame-ancestors等关键指令。
直接加 Content-Security-Policy HTTP 响应头，比靠 JS 过滤或 HTML 转义更底层、更可靠。它不是“修补漏洞”，而是让浏览器根本不敢执行非法脚本。
为什么 script-src 'self' 不能防住 XSS？
常见错误是只写 script-src 'self' 就以为安全了——其实 <script>alert(1)</script>、eval()、内联事件（如 onclick="doSomething()"）默认全被放行，除非你显式禁止。
-
script-src 'self' https://cdn.example.com：只限制外部脚本来源，不碰内联脚本 - 要禁内联，必须不加
'unsafe-inline'，再配合nonce或hash - 启用
default-src 'none'后，所有资源类型（img、style、font等）都需显式声明，否则加载失败（404）
用 nonce 还是 hash？关键看脚本是否动态
两者都能合法化特定内联脚本，但机制不同：nonce 是服务端每次响应生成一次随机值；hash 是对脚本内容做 SHA256 摘要。选错会导致脚本白屏或策略失效。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
nonce：<script nonce="abc123">...</script>+ 响应头配script-src 'nonce-abc123'；务必每次请求生成新值，硬编码或固定字符串等于形同虚设 - 用
hash：算出sha256-开头的摘要（如sha256-BzLdO9X...），写进头里；适合静态内联脚本，动态拼接的脚本无法预计算 hash - 别混用：一个策略里同时写
'nonce-xxx'和'sha256-...'是允许的，但浏览器只匹配其一；没匹配上的脚本仍被拦截
哪些指令容易被忽略却很关键？
CSP 对 base-uri、form-action、frame-ancestors 这些指令默认宽松，不显式配置就可能被利用。
-
base-uri 'self'：防止恶意<base href="http://attacker.com">劫持所有相对 URL -
form-action 'self'：阻止表单提交到第三方，防 CSRF 数据外泄 -
frame-ancestors 'none'或'self'：防止被嵌入钓鱼页面（点击劫持） -
object-src 'none'：禁用 Flash / Java 插件等老旧攻击面
开发期怎么试，才不会炸掉线上页面？
别一上来就 blocking。用 Content-Security-Policy-Report-Only 头 + report-uri 或 report-to 先观测违规行为，确认无误后再切到正式策略。
- HTTP 响应头优先于
<meta http-equiv="Content-Security-Policy">；后者仅在无法改服务器时兜底，且不支持report-uri、frame-ancestors等关键指令 - iframe、Worker、fetch 请求等子资源不受父页面 CSP 影响，各自响应头独立控制——主页面加了 CSP，但 API 返回的富文本 HTML 片段没带头，照样被绕过
- 策略中每个空格、引号、分号都敏感；少个单引号或漏个分号，整条策略会被浏览器忽略（静默失效）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
