HTTP安全头必须由服务端配置，因浏览器不认设置的CSP、X-Frame-Options等关键头；版CSP功能受限且被逐步废弃，X-Content-Type-Options等完全无效。
直接加 HTTP 响应头比在 <meta> 里模拟更可靠，浏览器对 Content-Security-Policy、X-Content-Type-Options 等关键安全头根本**不认 <meta> 写法**，只响应真实 HTTP 头。
为什么不能用 配置 CSP 和 X-Frame-Options
浏览器明确限制了哪些安全头允许通过 <meta> 设置：Content-Security-Policy 在部分浏览器中支持 <meta http-equiv="Content-Security-Policy">，但存在严重缺陷；X-Frame-Options、X-Content-Type-Options、Strict-Transport-Security 等**完全不支持 <meta> 形式**，写了也无效。
-
<meta http-equiv="Content-Security-Policy">无法设置report-uri或report-to，也无法用于 worker、iframe 子上下文，策略作用域受限 - Chrome 和 Safari 已逐步弱化甚至废弃
<meta>版 CSP，仅保留对简单指令（如default-src）的兼容 -
X-Frame-Options若写成<meta http-equiv="X-Frame-Options">，所有主流浏览器均忽略——这是硬性规范，不是兼容问题 - 服务端未发头、只靠前端塞
<meta>，等于把安全防线建在客户端可篡改的 HTML 里，形同虚设
必须由服务端注入的 4 个关键安全头
这些头必须通过 Nginx、Apache、Express、Spring Boot 等后端或 CDN 配置，不能依赖前端代码生成：
-
Content-Security-Policy：防御 XSS 的核心，需配合nonce或hash控制内联脚本，禁用'unsafe-inline'和'unsafe-eval' -
X-Content-Type-Options: nosniff：阻止 MIME 类型嗅探，防止.jpg文件被当作 JS 执行 -
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none'：防点击劫持，二者选其一（后者更现代） -
Strict-Transport-Security: max-age=31536000; includeSubDomains：强制 HTTPS，且需确保全站已稳定支持 HTTPS，否则用户将无法访问
CSP 中容易被忽略的指令组合
只配 script-src 'self' 不够，很多攻击面藏在边缘指令里：
立即学习“前端免费学习笔记（深入）”；
-
base-uri 'self'缺失 → 攻击者可注入<base href="https://evil.com">，让所有相对路径请求被劫持 -
form-action 'self'缺失 → 表单可能被提交到第三方，成为 CSRF 或数据泄露通道 -
frame-ancestors 'none'未设 → 页面可被嵌入钓鱼页，配合 UI 伪装诱导点击 -
upgrade-insecure-requests未启用 → 混合内容（HTTP 资源）仍可能加载，破坏 HTTPS 完整性
开发期调试 CSP 的实用姿势
上线前别直接 blocking，先用 report-only 模式收数据：
- 响应头用
Content-Security-Policy-Report-Only替代Content-Security-Policy - 搭配
report-to（推荐）或report-uri（旧版）收集违规日志，例如：report-to /csp-report-endpoint - 用浏览器 DevTools → Application → Manifest/CSP 查看实时拦截详情，注意区分是主文档还是 iframe worker 的策略
- 遇到白屏别急着加
'unsafe-inline'，先查是否漏了nonce值传递，或服务端没把 nonce 注入到<script nonce="xxx"></script>和响应头里
最常被跳过的其实是 base-uri 和 form-action 这两个指令，它们不报错、不显式拦截资源，但一旦缺失，就等于给攻击者留了静默利用的后门。配置时务必逐条核对，而不是复制粘贴模板就完事。
