安全响应头在防什么
响应头是成本最低的纵深防御：HSTS 阻止降级到明文、CSP 缓解跨站脚本、X-Content-Type-Options 阻止 MIME 嗅探、Referrer-Policy 控制外发来源信息。它们不能替代输入输出处理，但配置成本低、收益稳定。核查的重点是覆盖面与一致性：主站配了不代表 API 与子域也配了，同一个域名下不同路径的响应头也常不一致。
基本信息
| 必查项 | HSTS、CSP、X-Content-Type-Options、Referrer-Policy |
|---|---|
| 扩展项 | Permissions-Policy、X-Frame-Options、COOP 与 COEP |
| 核查方式 | 按域名清单批量抓取响应头，逐域名建立现状矩阵 |
| 范围要点 | 主站、API、子域、静态资源域都要覆盖 |
| 产出 | 逐域名头部现状表 + 缺失项与优先级建议 |
典型使用场景
- 新系统上线的安全基线核查
- 子域扩张后复核：新上线的域名是否继承了统一响应头配置
- 为跨站脚本类问题提供纵深防御建议
- 评估 HSTS 的落地情况与预加载申请条件
- 修复验证：确认响应头在全部入口生效而不只在首页
批量抓取示例
批量抓取示例
# Linux/macOS：按域名清单逐个抓取，仅看响应头
for d in app.example.com api.example.com static.example.com; do
echo "== $d =="
curl -sI https://$d/ | grep -Ei 'strict-transport|content-security|x-content-type|referrer-policy'
done
# Windows PowerShell 可用 curl.exe 代替，或使用 Invoke-WebRequest 的 Headers 属性
# 记录：域名 + 每个头部的取值或缺失，输出矩阵头部与作用
| 响应头 | 作用 | 常见问题 |
|---|---|---|
| Strict-Transport-Security | 强制后续请求使用 HTTPS | 缺少 max-age，或未评估子域包含的影响 |
| Content-Security-Policy | 限制脚本与资源来源，缓解跨站脚本 | 含 unsafe-inline 或通配源，实际防护很弱 |
| X-Content-Type-Options | 禁止浏览器猜测内容类型 | 缺失导致上传文件被当作脚本执行 |
| Referrer-Policy | 控制来源信息外发 | 缺失时敏感路径可能泄露给第三方站点 |
响应头属于纵深防御：不能替代输入输出处理，但成本低、收益稳定，适合作为基线要求统一落地。
HSTS 开启 includeSubDomains 与预加载前要先确认所有子域都能提供 HTTPS：一旦提交预加载，回退代价很高。
核查前先明确目标域名清单与用途分类：面向公网的用户站点、仅内部调用的 API 域与纯静态资源域对响应头的要求不同，内部域通常由网关统一注入，把内网域按公网标准逐条开缺陷会产生大量无效结论。
现状矩阵模板
现状矩阵模板
域名 | HSTS | CSP | X-Content-Type-Options | Referrer-Policy | 备注
app.example.com | 有(max-age 31536000) | 有(含 unsafe-inline) | 有 | 缺失 | CSP 需收紧
api.example.com | 缺失 | 缺失 | 有 | 缺失 | 建议网关统一注入
static.example.com | 有(无子域包含) | 缺失 | 有 | 有 | 静态域可放宽 CSP
# 记录方式：逐域名逐头部填现状，缺失项直接留空，复核时一眼可见