网站安全响应头配置实战：HSTS、CSP、X-Frame-Options 一次配齐

引言

说到网站安全，很多个人站长第一反应是改强密码、关端口、装防火墙，这些当然重要，但大多数人忽略了一层几乎零成本、零性能损耗的防护——HTTP 安全响应头。它是服务器随网页一起发给浏览器的一组指令，告诉浏览器"这个网站应该怎么被对待"：只允许 HTTPS 访问、不允许被其他网站嵌入、不允许脚本乱加载外部资源等等。配置得当的话，能有效防住协议降级攻击、点击劫持、MIME 嗅探、XSS 扩散等一系列常见风险，而且几分钟就能配完。本文就把常用安全响应头逐个讲透，并给出 Nginx 的完整实战配置。

一、为什么站长要重视响应头

安全响应头之所以性价比高，是因为它把安全防线前置到了浏览器端。传统思路是在服务器端拦截攻击，但有些攻击发生在响应到达浏览器之后，比如一个恶意页面试图把你的网站嵌进 iframe 里诱导用户点击，服务器端根本无从感知，只有浏览器配合响应头的指令才能拦下来。另一个现实是，草根站长的网站经常挂在虚拟主机或低配 VPS 上，装不了复杂的 WAF，而安全响应头是纯配置层面的东西，任何环境都能用。现在业界甚至有了专门的评级网站，比如 SecurityHeaders 这类工具会给你的网站打分，分数高的网站在用户和搜索引擎眼中都是加分项。

二、逐个认识核心安全响应头

下面按重要程度逐个介绍个人站长最常用的几个安全响应头。

1. Strict-Transport-Security（HSTS）

HSTS 的作用是强制浏览器只能通过 HTTPS 访问你的网站。它的出现是为了解决一个叫 SSL 剥离的攻击：攻击者在用户和网站之间拦截流量，把 HTTPS 链接悄悄降级成 HTTP，用户毫无察觉地以明文方式浏览和提交数据。启用 HSTS 后，浏览器在有效期内会记住"这个网站必须用 HTTPS"，任何 HTTP 请求都在浏览器本地被拦截并自动升级，攻击者根本没有机会介入。

典型的配置值是 max-age=31536000 表示有效期一年，includeSubDomains 表示子域名同样强制 HTTPS，preload 则表示申请加入浏览器的 HSTS 预加载列表。这里有个非常重要的坑：includeSubDomains 和 preload 一定要在全站所有子域名都支持 HTTPS 之后才能开，否则某个还在用 HTTP 的子域名会直接无法访问。

2. X-Frame-Options 与 CSP 的 frame-ancestors

X-Frame-Options 用来防止点击劫持，也就是别人把你的网页偷偷嵌进他的 iframe 里，覆盖一层透明按钮诱导用户点击。取值 DENY 表示任何网站都不能嵌入，SAMEORIGIN 表示只允许同源页面嵌入。对于没有正当被嵌入需求的普通内容站，直接用 DENY 或 SAMEORIGIN 即可。更现代的替代方案是 CSP 指令里的 frame-ancestors，它能精确指定允许嵌入的域名白名单，比 X-Frame-Options 更灵活，两者同时设置时浏览器以 frame-ancestors 为准。

3. X-Content-Type-Options

这个头只有一个取值 nosniff，作用是禁止浏览器对响应内容做 MIME 类型嗅探。有些老浏览器在服务器声明的内容类型和实际内容不符时，会自作聪明地去猜测真实类型，攻击者可以利用这一点，把恶意脚本伪装成图片上传，再诱导浏览器按脚本解析。设置 nosniff 后，浏览器严格按 Content-Type 处理，这类攻击路径就被封死了。

4. Referrer-Policy

这个头控制浏览器在跳转时携带多少来源信息。默认情况下，你的网站里某个链接跳转到别的网站时，对方能看到访客是从你网站的哪个具体页面过来的，这在涉及登录态或敏感路径时存在泄露风险。对个人站长来说，推荐设置为 strict-origin-when-cross-origin，它的含义是同源请求携带完整来源，跨域请求只携带域名，HTTPS 降级到 HTTP 时完全不携带，是安全性和功能性的最佳平衡。

5. Content-Security-Policy（CSP）

CSP 是这组头里功能最强也最复杂的一个，它通过白名单机制限制页面可以加载和执行的资源：脚本、样式、图片、字体、连接、框架分别指定允许的来源，不在白名单里的一律拦截。它的最大价值在于，即使网站存在 XSS 漏洞，攻击者注入的脚本也执行不了，因为浏览器会直接拦下所有非白名单来源的脚本。CSP 常用指令包括 default-src 作为兜底、script-src 管脚本、style-src 管样式、img-src 管图片、connect-src 管 AJAX 和 WebSocket、frame-src 管 iframe。

6. Permissions-Policy 与 X-XSS-Protection

Permissions-Policy 用来关闭浏览器的高级功能权限，比如摄像头、麦克风、地理位置，个人网站基本用不到这些功能，全部关掉可以减少攻击面。另外要提醒的是 X-XSS-Protection，这个头在老教程里经常被推荐设置成 1; mode=block，但现代浏览器已经废弃了它，甚至可能引入新的安全问题，正确做法是不要设置或者显式设置为 0，把 XSS 防护交给 CSP 来处理。

三、Nginx 实战配置

为了便于维护，建议把安全响应头写成一个独立的配置文件，比如 /etc/nginx/conf.d/security-headers.conf，然后在需要的 server 块里用 include 引入：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;
add_header Referrer-Policy strict-origin-when-cross-origin always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://pagead2.googlesyndication.com https://googleads.g.doubleclick.net; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; font-src 'self' data:; frame-src https://googleads.g.doubleclick.net https://pagead2.googlesyndication.com" always;

每条指令末尾的 always 参数很关键，它保证即使响应是 404、500 之类的错误页面，安全头也会照常发送，避免错误页面成为防护盲区。上面的 CSP 示例已经为 Google AdSense 广告放行了脚本、样式和框架来源，挂广告的站长可以直接参考。

这里必须重点提醒 Nginx 的一个经典陷阱：add_header 指令存在继承覆盖规则，只要当前配置层级里出现任何一条 add_header，上层 http 或 server 级别定义的所有 add_header 就会整体失效。也就是说，如果你在某个 location 块里单独写了一条 add_header，而这个 server 块的安全头是在外层定义的，那么这个 location 下的响应就不会带任何安全头。解决方法是把安全头也放到对应的 location 层级，或者干脆统一只在 server 级别定义、避免在 location 里再写 add_header。排查线上问题时，如果发现某个路径的响应头缺失，优先检查是不是这个原因。

与 HSTS 相关的还有一个容易忽视的细节：从 HTTP 跳转到 HTTPS 的那条 301 响应本身，最好也带上安全头。因为浏览器只有在收到带 HSTS 头的 HTTPS 响应之后，才会记住"强制 HTTPS"的策略，如果首次访问走的是 80 端口跳转，而跳转响应里光秃秃的没有 HSTS，那么这次访问仍然暴露在明文连接之下。Nginx 里负责 80 端口跳转的 server 块如果与外层配置不在同一层级，记得为它单独引入安全头配置文件，或者直接复用 include 语句，保证每一次响应都带着完整的防护头。

四、验证配置效果

配置完成后，用 curl 就能快速验证：

curl -sI https://www.zz1984.com/ | grep -iE "strict-transport|x-content-type|x-frame|referrer-policy|content-security|permissions-policy"

如果各条安全头都出现在响应里，说明配置生效了。想更全面地评估，可以把网站地址丢到 SecurityHeaders 这类在线评级工具里，它会逐项检查并给出 A 到 F 的评分和缺失项说明，是排查漏配的得力助手。需要特别提醒的是 CSP：它是所有安全头里最"娇气"的，规则写得太严可能误伤正常功能，比如某些统计脚本、广告代码、第三方字体加载不出来。所以调整 CSP 时建议先用 Content-Security-Policy-Report-Only 模式上线观察，这个头只上报违规不拦截，等根据上报记录把白名单补全了，再切换成真正的 Content-Security-Policy。

五、避坑清单

• HSTS 的 preload 一旦提交就很难撤回，浏览器预加载列表的移除流程漫长，务必在全站 HTTPS 稳定运行一段时间后再申请；
• includeSubDomains 会波及所有子域名，有子域名还在跑 HTTP 服务的话千万别开，否则那些服务会直接失联；
• 记住 add_header 的继承覆盖规则，location 里的 add_header 会屏蔽外层全部设置，这是响应头时有时无的头号原因；
• CSP 不要一上来就上最严策略，先开 Report-Only 模式收集违规报告，再逐步收紧，否则广告、统计代码随时可能"消失"；
• 配置完一定要测试手机端和电脑端各主流浏览器各看一遍关键页面，确认没有功能被误伤，再放心推广到全站。

六、结语

安全响应头是个人站长最容易上手也最容易被忽视的一层防护：不需要额外软件，不占用服务器资源，不影响网站性能，只要在 Nginx 配置里加几行就能显著提升网站的安全形象和防护能力。建议按照本文的顺序，先把 HSTS、nosniff、X-Frame-Options 这几个基础头配好，再花点时间把 CSP 调校到位，最后用在线工具打个分验证成果。安全没有一劳永逸，但把能免费做到的基础防护都做扎实，至少能让你的网站在绝大多数常见攻击面前不再是"软柿子"。