应使用 curl -I 直接查看原始 HTTP 响应头以准确排查安全头缺失问题，重点关注 Strict-Transport-Security、X-Content-Type-Options、X-Frame-Options、Content-Security-Policy 和 Referrer-Policy 是否存在且值有效，避免依赖浏览器开发者工具导致误判。
用 curl 直接看响应头，别依赖浏览器开发者工具
浏览器开发者工具的 Network 面板默认会过滤掉部分响应头（比如被插件、扩展或 DevTools 自身逻辑隐藏的），容易误判“头已存在”。真实漏洞排查必须绕过浏览器，直接观察原始 HTTP 响应。
执行命令：curl -I https://your-domain.com（加 -k 跳过证书校验，仅限测试环境）；生产环境建议用 curl -I --resolve your-domain.com:443:IP地址 确保走目标服务器而非 CDN 缓存。
- 重点关注是否返回了
Strict-Transport-Security、X-Content-Type-Options、X-Frame-Options、Content-Security-Policy、Referrer-Policy - 如果某头存在但值为空（如
X-Frame-Options:后面没值），等同于缺失，浏览器会忽略 -
add_header在 Nginx 的if块里写会导致该头完全不生效——这是最常踩的配置陷阱
区分“服务端未配”和“被中间层覆盖”
很多线上环境实际是多层代理：CDN → WAF → 负载均衡 → 应用服务器。你改了 Nginx 配置，但 CDN 或 WAF 已经返回了不含安全头的响应，你的修改就白做了。
排查步骤：
立即学习“前端免费学习笔记（深入）”；
- 先在应用服务器本机
curl -I http://127.0.0.1:8080，确认后端服务本身是否输出了正确响应头 - 再从外网请求，对比两次响应头差异；若差异明显，说明中间层劫持了响应
- Cloudflare、阿里云WAF、腾讯云EdgeOne 等平台默认不透传或主动删除某些头（尤其是
Content-Security-Policy），需进控制台单独开启“自定义响应头透传”或手动添加
CSP 头缺失或配置错误比其他头更危险
Content-Security-Policy 是唯一能实质性缓解 XSS 的响应头，但它极易配错：配太松等于没配，配太严导致功能崩溃，且 <meta> 标签方式在生产环境完全无效。
- 绝对不要用
<meta http-equiv="Content-Security-Policy">上线——它无法拦截内联事件处理器（如onclick）、不支持nonce、且一旦服务端返回任意 CSP 响应头（哪怕拼写错误），<meta>就被浏览器静默丢弃 -
default-src 'none'必须作为起点；漏写connect-src 'self'会导致所有fetch()请求 0 字节响应并静默失败 - 开发阶段先用
Content-Security-Policy-Report-Only收集违规日志，再逐步收紧策略，避免上线即雪崩
HSTS 设置后无法回退，上线前必须验证有效期与子域覆盖
Strict-Transport-Security 一旦被浏览器接收，就会强制后续所有请求走 HTTPS，且在 max-age 时间内无法通过清除缓存解除——这意味着配错就等于让整个域名暂时不可访问。
- 首次上线务必设
max-age=300（5 分钟），验证无误后再逐步延长到31536000（1 年） - 加
includeSubDomains前，确保所有子域（包括cdn.your-domain.com、api.your-domain.com）都已支持 HTTPS，否则子域将彻底无法加载 - 想进 Chrome / Firefox HSTS 预加载列表？必须满足：全站 HTTPS +
max-age ≥ 31536000+includeSubDomains+preload参数，且需手动提交申请；没加preload就只是普通 HSTS
curl -I 对比源站和外网响应，比跑十遍扫描工具都管用。 
