安全响应头是什么
安全响应头是服务端用响应头给浏览器下达的一组安全策略：限定页面只能从哪些来源加载脚本，禁止浏览器猜测文件类型，避免页面被嵌进别人站点，控制 Referer 泄漏多少信息。它们不改变业务逻辑，却能一次性挡掉大量常见前端攻击面，属于成本极低、收益明确的基线配置。生产站点应把这些头当作上线清单的一部分，并用工具定期体检。
安全头清单
| 头 | 示意值 | 防御目标 |
|---|---|---|
| Strict-Transport-Security | max-age=31536000; includeSubDomains | SSL 剥离降级 |
| Content-Security-Policy | default-src 'self' | XSS 与资源注入 |
| X-Content-Type-Options | nosniff | MIME 类型嗅探 |
| X-Frame-Options / frame-ancestors | SAMEORIGIN / 'self' | 点击劫持 |
| Referrer-Policy | strict-origin-when-cross-origin | 来源信息泄漏 |
| Permissions-Policy | camera=(), microphone=() | 设备能力滥用 |
基本信息
| 规范 | HSTS RFC 6797、CSP W3C、Referrer-Policy W3C |
|---|---|
| 生效位置 | HTTPS 响应；部分头在 HTTP 上会被忽略 |
| 过渡手段 | CSP 可先用 Content-Security-Policy-Report-Only 观察 |
| 体检工具 | curl -sI 与 OWASP/Mozilla 的在线评分工具 |
| 覆盖范围 | 静态资源、API 与错误页都要带，不能只配首页 |
| 常见坑 | Nginx add_header 的继承与覆盖规则 |
典型使用场景
- 新站点上线前统一补齐安全头，通过体检工具评分
- 给静态资源域名与 API 域名分别配置合适的安全策略
- CSP 灰度：先用报告模式收集违规，再切换为强制模式
- 配合下载接口使用 nosniff，防止上传文件被当成脚本执行
- 排查体检报告里「某个 location 少了安全头」的路径级缺失
Nginx 统一添加
Nginx 统一添加
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=()" always;
# CSP 建议先在 Report-Only 模式观察，确认无误再切强制
add_header Content-Security-Policy-Report-Only "default-src 'self'" always;
# 注意：location 中再写 add_header，会覆盖 http/server 层级的全部 add_header，需重复声明或用 include 片段复用HSTS 只对有 TLS 的响应生效，且一旦下发就会被浏览器记住 max-age 秒数；调试阶段先用较短 max-age，确认全站 HTTPS 正常后再改为一年的长值，避免把错误的子域配置锁死太久。
CSP 直接用强制模式上线容易误伤：内联脚本、第三方渲染组件都可能被拦掉。先开 Report-Only 收集违规报告，白名单收敛后再切强制，是避免「上线即白屏」的标准做法。