CSP 必须通过 HTTP 响应头配置才真正生效，<meta http-equiv="Content-Security-Policy"> 在生产环境基本无效，因其被响应头优先忽略、不支持 frame-ancestors/report-to 等关键指令、无法动态生成 nonce，且 Chrome 124+ 已限制 script-src 等核心功能。
配 CSP 不是写个 <meta> 就完事——它基本不生效，尤其对脚本、外链、动态执行等关键防护点完全失效。必须走 HTTP 响应头，且策略写错一条，资源就静默失败，连错误提示都不给。
为什么几乎没用
浏览器只在极少数低风险场景（如 base-uri、img-src）部分支持 <meta>，但 script-src、connect-src、frame-ancestors 等核心指令一律静默忽略。你写了 script-src 'self' 在 <meta> 里，<script src="https://evil.com/x.js"></script> 依然能加载执行，控制台还不会报错。
- 服务端返回任意 CSP 响应头（哪怕语法错误），
<meta>立刻被彻底覆盖 - CDN、反向代理、SSR 框架（如 Next.js/Vue SSR）通常不解析或丢弃
<meta>中的 CSP - 本地用
file://或 VS Code Live Server 打开时，CSP 全面关闭；Chrome 124+ 还直接禁掉script-src的<meta>支持
怎么确认 CSP 真生效了
别看控制台有没有报错，要看响应头本身是否存在且格式正确：
- 打开 Chrome DevTools → Network → 刷一次页面 → 找到 HTML 请求 → 点开 Response Headers → 查找
content-security-policy（全小写，注意不是Content-Security-Policy大驼峰） - 用
curl -I https://yoursite.com/直接看响应头，确认字段存在且值非空 - 如果只看到
<meta http-equiv="Content-Security-Policy">，但响应头里没有，那等于没配
最小可行且真正起效的 CSP 配置
default-src 'self' 是起点，但光它不够——内联脚本、表单提交、iframe 嵌套、<base> 标签全是默认放行的后门。上线前至少补这 4 条：
立即学习“前端免费学习笔记（深入）”；
-
script-src 'self' 'nonce-{random}'：服务端每次生成新 nonce（如abc123），HTML 中写<script nonce="abc123">...</script>；绝不能硬编码或复用 -
style-src 'self' 'unsafe-inline'：CSS 内联太常见，先放开，后续再用 hash 替代 -
base-uri 'self'：防止攻击者注入<base href="http://evil.com">劫持所有相对路径请求 -
form-action 'self'：阻止表单提交到第三方，防 CSRF 数据泄露
漏掉其中任何一条，都可能让攻击者绕过防护。比如没设 base-uri，恶意 JS 就能改掉整个页面的资源加载路径。
Nginx / Express / FastAPI 怎么加响应头
不同环境写法差异大，但核心就一条：必须是响应头，不是 HTML 标签。
- Nginx：
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{random}'; base-uri 'self'; form-action 'self';" always;（注意always，否则 304 响应不带头） - Express：
res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self' 'nonce-" + nonce + "'; ...");（nonce必须每次请求动态生成） - FastAPI：
response.headers['Content-Security-Policy'] = "default-src 'self'; ..."（不要用X-Content-Security-Policy，那是旧草案，现代浏览器不认）
所有配置里，script-src 里只要出现 'unsafe-inline' 或 'unsafe-eval'，就等于关掉了 XSS 主要防线——不是“暂时妥协”，而是明确放弃防护能力。
