HTTP 响应头安全配置清单：从 XSS 防御到纵深加固

在 Web 安全领域，我们常常把大量精力投入到代码审计、输入过滤和 WAF 规则上，却容易忽略一个成本极低、收益极高的防线——HTTP 响应头。响应头由服务器在返回资源时附带，浏览器会依据其中的安全指令决定“能做什么、不能做什么”。配置得当，可以在不修改一行业务代码的前提下，拦截大量 XSS、点击劫持、信息泄露和协议降级攻击。

本文整理了一份可直接落地的 HTTP 响应头安全配置清单，并结合 XSS 的常见方式、前端防御思路、SQL 注入的写法以及 Linux 服务器加固，形成一套完整的纵深防御视角。

一、为什么响应头是 XSS 防御的第一道闸门

XSS 的常见方式主要有三类：反射型、存储型和 DOM 型。反射型通过诱骗用户点击带恶意参数的链接，让服务器把脚本“反射”回页面；存储型把恶意脚本写入数据库，在评论、昵称、文章等位置持久化执行；DOM 型则不经过服务器，由前端 JavaScript 直接读取 location.hash、innerHTML 等危险源并写入页面。

前端防御的核心原则是：不信任任何外部输入，输出到不同上下文时使用不同编码。例如，输出到 HTML 正文要转义 < > & " '，输出到属性要加引号并转义，输出到 JavaScript 要使用 JSON.stringify 或专用编码，输出到 URL 要使用 encodeURIComponent。同时，尽量使用 textContent 而不是 innerHTML，对富文本使用 DOMPurify 等成熟库做白名单净化。

但前端防御有一个天然短板：一旦某处遗漏，攻击就会发生。此时，响应头中的 CSP 就是最后一道“兜底”。CSP 通过白名单限制脚本来源，即使页面被注入了 <script>，浏览器也会拒绝执行。因此，响应头不是替代前端编码，而是为前端防御提供纵深。

二、核心安全响应头清单

1. Content-Security-Policy（CSP）

CSP 是抵御 XSS 最有力的响应头。推荐从限制性策略起步，例如：

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

关键点：避免使用 unsafe-inline 和 unsafe-eval；对必须的内联脚本使用 nonce 或 hash；object-src 'none' 可阻止 Flash 等插件类攻击；base-uri 'self' 防止 <base> 标签劫持相对路径。上线前先用 Content-Security-Policy-Report-Only 观察误报。

2. X-Content-Type-Options

X-Content-Type-Options: nosniff

该头阻止浏览器对 MIME 类型进行嗅探。没有它，一个被上传的“图片”若内容实为 HTML，浏览器可能按 HTML 执行，从而形成 XSS。加上 nosniff 后，浏览器严格按 Content-Type 处理资源。

3. X-Frame-Options 与 frame-ancestors

X-Frame-Options: DENY

或使用 CSP 的 frame-ancestors 'none'。二者用于防御点击劫持：攻击者用透明 iframe 覆盖页面，诱导用户点击。现代浏览器优先支持 frame-ancestors，但保留 X-Frame-Options 可兼容旧环境。若业务需要被特定站点嵌入，应使用白名单而非直接放开。

4. Strict-Transport-Security（HSTS）

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

HSTS 强制浏览器在指定时间内只通过 HTTPS 访问，防止 SSL 剥离和协议降级。includeSubDomains 覆盖子域名，preload 可申请加入浏览器预加载列表。注意：一旦开启，回退成本很高，建议先从小 max-age 测试。

5. Referrer-Policy

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

控制 Referer 中携带的信息量，避免把完整 URL（可能含 token、内部路径）泄露给第三方。更严格的 no-referrer 适合敏感系统，但可能影响统计和防盗链。

6. Permissions-Policy

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

按需关闭浏览器特性，减少被恶意脚本滥用的面。例如，若业务不需要定位，直接禁用可降低隐私风险。

7. 其他辅助头

• X-XSS-Protection: 0：现代浏览器已弃用该旧过滤器，建议显式关闭，避免其引入新的侧信道问题，转而依赖 CSP。
• Cross-Origin-Opener-Policy、Cross-Origin-Resource-Policy、Cross-Origin-Embedder-Policy：用于隔离跨源窗口和资源，防御 Spectre 类侧信道及跨源数据泄露。

三、与 SQL 注入、服务器加固的联动

响应头解决的是浏览器侧信任问题，但服务端漏洞同样不能忽视。MySQL 防止 SQL 注入的几种写法中，最有效的是参数化查询（Prepared Statement）。例如在 PHP 中使用 PDO：

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');
$stmt->execute([$email]);

在 Java 中使用 PreparedStatement，在 Python 中使用 cursor.execute(sql, params)。核心是让 SQL 结构与数据分离，绝不用字符串拼接。若必须动态拼接表名或排序字段，应使用白名单映射，而不是直接拼接用户输入。ORM 的链式查询通常也会参数化，但要注意 raw、whereRaw 等逃逸口。

Linux 服务器安全加固清单则从主机层提供保障：及时更新补丁、最小化安装、关闭无用端口和服务、使用 SSH 密钥登录并禁用 root 远程登录、配置防火墙仅放行必要端口、启用 fail2ban 防暴力破解、对敏感目录设置最小权限、开启审计日志并集中收集。Web 服务器层面，Nginx/Apache 应隐藏版本号、限制请求体大小、配置超时和限速，避免信息泄露与资源耗尽。

四、落地建议与检查清单

部署响应头时，建议按以下顺序推进：

1. 先启用 X-Content-Type-Options、X-Frame-Options、Referrer-Policy，风险低、见效快。
2. 配置 HSTS，从小 max-age 开始，确认全站 HTTPS 无误后逐步加大。
3. 以 Report-Only 模式部署 CSP，收集报告、修复内联脚本，再切换为强制模式。
4. 按业务需要收紧 Permissions-Policy 和跨源隔离头。
5. 将响应头配置纳入基础设施即代码和自动化测试，防止回退。

最后，用一句话总结：前端编码负责“正确输出”，CSP 等响应头负责“即使出错也不执行”，参数化查询负责“数据不变成代码”，服务器加固负责“系统不被轻易攻破”。四者叠加，才是完整的 Web 安全纵深防御。

未经允许不得转载：任鹏个人博客 » HTTP 响应头安全配置清单：从 XSS 防御到纵深加固