Web 安全加固清单：HTTP 安全响应头配置指南

在 Web 安全领域，SQL 注入、XSS、CSRF 等攻击手段长期占据 OWASP Top 10 榜单。大多数开发者将精力集中在输入验证、参数化查询和 CSRF Token 等应用层防护上，却往往忽略了一道成本极低、效果显著的安全防线——HTTP 安全响应头。本文将系统梳理核心安全响应头的配置方法，帮助你以最小改动大幅提升应用的防御能力。

为什么 HTTP 安全响应头如此重要

HTTP 响应头是服务器与浏览器之间的“安全契约”。通过设置特定的响应头，服务器可以指示浏览器启用内置的安全机制，从而在攻击发生之前就将其阻断。与代码层面的修复相比，响应头配置具有以下优势：

• 零代码侵入：无需修改业务逻辑，在 Nginx、Apache 或应用框架层面即可完成。
• 浏览器原生支持：现代浏览器对安全响应头的支持已经非常成熟。
• 纵深防御：即使应用层存在疏漏，响应头仍能提供额外一层保护。

核心安全响应头详解

1. Content-Security-Policy（CSP）——对抗 XSS 的利器

CSP 是目前最强大的 XSS 缓解手段。它通过白名单机制限制浏览器可以加载和执行的资源来源，从根本上遏制内联脚本和恶意外部脚本的执行。

一个推荐的起步配置：

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

关键指令说明：

• default-src 'self'：默认只允许加载同源资源。
• script-src 'self'：禁止内联脚本和 eval，这是阻止 XSS 的核心。
• frame-ancestors 'none'：防止页面被嵌入 iframe，等效于 X-Frame-Options。
• form-action 'self'：限制表单只能提交到同源地址，降低数据外泄风险。

建议先使用 Content-Security-Policy-Report-Only 模式观察一段时间，确认不影响业务后再正式启用。

2. Strict-Transport-Security（HSTS）——强制 HTTPS

HSTS 告诉浏览器在指定时间内只能通过 HTTPS 访问该站点，彻底杜绝 SSL 剥离攻击：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000：一年内强制 HTTPS。
• includeSubDomains：所有子域名同样生效。
• preload：申请加入浏览器预加载列表，首次访问即强制 HTTPS。

需要注意的是，一旦启用 HSTS，在 max-age 到期前无法回退到 HTTP，配置前请确保全站 HTTPS 已稳定运行。

3. X-Content-Type-Options——阻止 MIME 类型嗅探

浏览器有时会忽略声明的 Content-Type，自行“嗅探”文件类型，这可能将上传的图片当作脚本执行：

X-Content-Type-Options: nosniff

这个头只有一个有效值 nosniff，配置简单但效果明确，建议所有站点启用。

4. X-Frame-Options——防御点击劫持

点击劫持（Clickjacking）通过将目标页面嵌入透明 iframe 诱导用户点击。X-Frame-Options 可以有效阻止：

X-Frame-Options: DENY

可选值包括 DENY（完全禁止嵌入）和 SAMEORIGIN（仅允许同源嵌入）。如果已配置 CSP 的 frame-ancestors，此头可作为兼容旧浏览器的补充。

5. Referrer-Policy——控制 Referer 信息泄露

默认情况下，浏览器会在跨域请求中携带完整的 Referer 头，可能泄露敏感 URL 参数：

Referrer-Policy: strict-origin-when-cross-origin

该策略在同源请求中发送完整路径，跨域时仅发送源（origin），HTTPS 降级到 HTTP 时不发送，兼顾了功能与隐私。

6. Permissions-Policy——限制浏览器特性

该头用于禁用不需要的浏览器 API，减少攻击面：

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

按需开启，不需要的功能一律禁用。

7. Set-Cookie 安全属性——保护会话

虽然严格来说不是响应头，但 Cookie 的安全属性同样关键，尤其是对抗 CSRF 和会话劫持：

Set-Cookie: sessionid=xxx; HttpOnly; Secure; SameSite=Lax; Path=/

• HttpOnly：禁止 JavaScript 读取，缓解 XSS 窃取 Cookie。
• Secure：仅通过 HTTPS 传输。
• SameSite=Lax：限制跨站请求携带 Cookie，有效缓解 CSRF。

完整配置示例（Nginx）

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

注意 always 参数确保即使返回错误响应也会带上这些头。

验证与持续监控

配置完成后，可通过以下方式验证：

1. 浏览器开发者工具：在 Network 面板查看响应头是否生效。
2. 在线检测工具：如 securityheaders.com、Mozilla Observatory，可给出评分和改进建议。
3. 自动化监控：将安全头检查纳入 CI/CD 流程，防止配置被意外回退。

总结

HTTP 安全响应头是 Web 安全加固中投入产出比最高的一环。它无法替代参数化查询防御 SQL 注入、输入过滤防御 XSS、Token 校验防御 CSRF 等应用层措施，但能与这些措施形成纵深防御体系。建议按照以下优先级逐步落地：

1. 首先启用 HSTS、X-Content-Type-Options、X-Frame-Options 和 Cookie 安全属性——配置简单、风险低。
2. 其次配置 Referrer-Policy 和 Permissions-Policy。
3. 最后以 Report-Only 模式引入 CSP，逐步收紧策略直至正式启用。

安全加固没有终点，定期审查和更新响应头配置，才能持续抵御不断演变的攻击手法。

未经允许不得转载：任鹏个人博客 » Web 安全加固清单：HTTP 安全响应头配置指南