Security Headers

Security Headers 会请求目标网址并分析 HTTP 响应头，以 A+ 到 F 给出配置反馈；R 表示当前响应是重定向，需要继续跟随。它能快速发现 Content-Security-Policy、Strict-Transport-Security、Referrer-Policy 等头部缺失或警告，但评分只代表这组响应头，不是漏洞扫描，也不能证明网站整体安全。

先确认扫描的是最终 HTTPS 页面

输入完整网址并启用 follow redirects，可避免只检查 HTTP 或中间 301/302。报告中的 IP、时间、状态码和 raw headers 是复测基线；同一域名的首页、登录页、后台和静态资源可能由不同 CDN、反向代理或应用返回，不能用首页一次结果代表全部路径。需要减少扫描结果在首页展示时，可使用 hide 选项。

从缺失头追到实际响应层

读一份报告时先对照原始响应头

官方 API 示例的 summary 会同时给出 grade、gradeCap、各安全头状态、missingHeaders、validationErrors 和 rawHeaders。比如 rawHeaders 已出现 strict-transport-security: max-age=31536000; includeSubDomains; preload，说明 HSTS 不只是“存在”；还需确认所有子域都能长期使用 HTTPS，才能安全保留 includeSubDomains 或提交 preload。若 X-Frame-Options 显示未设置，但 CSP 已有 frame-ancestors，报告可能仍把该项视为已覆盖，不能机械补一条冲突策略。

CSP 被标为绿色也可能同时出现 validationErrors，例如 style-src 仍含 unsafe-inline。因此复测记录应保存具体头值和警告，而不是只比较 A、B 两个字母。

CSP 要先观察再收紧

Content-Security-Policy 对 XSS 防护很重要，也最容易因配置不当破坏登录、支付、统计、字体或嵌入内容。上线前可先在测试环境或 Report-Only 模式收集违规，按实际资源建立 source list，再逐步移除宽泛来源、unsafe-inline 或不必要的第三方域名。得到 A+ 不应成为牺牲功能或盲目放宽策略的理由。

修复后同时做功能和安全回归

1. 保存修复前的报告时间、原始头、缺失项和 grade cap 警告。
2. 在真正产生响应的 CDN、代理或应用层修改，避免多层重复覆盖。
3. 用浏览器网络面板或命令行确认最终响应，而不只看配置文件。
4. 复测关键路径、不同状态码与子域名，并检查登录、上传、支付和嵌入功能。
5. 把 Security Headers 分数与 TLS、依赖、身份验证、访问控制和应用漏洞测试分开记录。

API 适合持续检查但需要授权

官方 API 使用 q、hide、followRedirects 参数，并要求在 x-api-key 请求头提供 API Key。自动化检查应控制频率，只扫描自己管理或获准测试的目标，并把评分变化与部署版本关联。入口：https://securityheaders.com/