安全响应头补齐战：CSP、X-Frame-Options一次配到位

来源：互联网时间：2026-09-12

SSL 签名挂上（《SSL Labs冲A+：Mozilla配置生成器抄作业，HSTS加TLS1.3一步到位》的 A+ 只解决传输加密），浏览器安全报告里还有一排黄灯：缺少 Content-Security-Policy、未设置 X-Frame-Options、Referrer-Policy 未定义。这些安全响应头管的是另一类威胁：不是“传输路上被偷”，而是“页面被别人利用”——被嵌入钓鱼页、被注入的脚本带走数据、点击劫持。这篇把常用的几个头一次配齐，配完 Mozilla Observatory 这类检测工具能从 C 档直接拉到 A 档。

逐个说清每个头防什么。X-Frame-Options 防点击劫持：攻击者把你的页面嵌进他的页面上层，诱导用户在他做的假界面按钮上点击，实际点到的是你页面的功能。两个取值：DENY 完全禁止被嵌入，SAMEORIGIN 只允许同源嵌入（自己后台预览自己页面要用后者）。X-Content-Type-Options 防 MIME 嗅探：浏览器自作聪明猜文件类型是被利用的老漏洞，nosniff 强制浏览器按声明的内容类型处理。Referrer-Policy 管外链跳转时带不带完整 URL——你后台 URL 里带 token，用户从后台点个外链，token 就进了外站日志。

# Nginx 全局加安全头（http块或server块）
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
 
# HSTS在《SSL Labs冲A+：Mozilla配置生成器抄作业，HSTS加TLS1.3一步到位》配过，别重复加
# 注意 always 参数：4xx/5xx响应也要带头，不加只覆盖2xx/3xx

最复杂也最有价值的是 CSP（Content-Security-Policy）。它声明“本页允许从哪里加载什么类型的资源”，浏览器只执行白名单内的脚本，注入进来的恶意脚本没有执行机会——对 WordPress 这类插件生态庞大、 XSS 是头号风险的系统，CSP 是纵深防御里很硬的一层。但 CSP 配错会直接把站搞瞎（样式丢了、脚本全灭），所以标准动作是先用 Report-Only 模式观察：

# 第一步：Report-Only模式——只上报违规，不真正拦截
add_header Content-Security-Policy-Report-Only "
 default-src 'self';
 script-src 'self' 'unsafe-inline' https://pagead2.googlesyndication.com;
 style-src 'self' 'unsafe-inline';
 img-src 'self' data: https:;
 font-src 'self';
 frame-ancestors 'self';
 report-uri /csp-report;
" always;
 
# 观察一到两周，浏览器控制台和收集端点看违规报告
# 报告里出现的都是页面实际在用的资源，逐个加白名单
 
# 第二步：白名单稳定后去掉-Report-Only变成强制模式
# 并逐步尝试去掉unsafe-inline（它让CSP的XSS防护大打折扣）

WordPress 站点配 CSP 有两个现实难点要预判。一是插件常往页面塞内联脚本和内联样式，一刀切的严格 CSP 必然把插件功能搞坏——这就是为什么要从 Report-Only 起步，让真实流量替你画出白名单。二是 'unsafe-inline' 那一项：它相当于给所有内联脚本开了绿灯，严格说削弱了 CSP 的防注入能力，但 WP 生态眼下完全离开它不现实，务实做法是先带着它上强制模式，拿到“配置存在”这八十分，再借 nonce 或 hash 方案逐步收紧——CSP 是个渐进工程，别指望一步到位。

配完验证，两个工具配合用：

# 命令行确认所有头都发出来了

curl -sI https://example.com/ | grep -iE "x-frame|x-content|referrer|content-security"

# 在线检测工具给出评级和缺口清单

# securityheaders.com —— 安全头专项检测

# developer.mozilla.org 的 Observatory —— 综合评级

# 期望结果：主要头全部出现，评级B以上

# CSP强制模式稳定运行一段时间后可冲A

收尾说下这几个头和已有配置的关系。它们和《SSL Labs冲A+：Mozilla配置生成器抄作业，HSTS加TLS1.3一步到位》的 HSTS 各管一段：HSTS 保证连接用 HTTPS，这批头保证页面内容不被滥用，合起来才是完整的浏览器侧防线。另外注意 add_header 的继承陷阱——Nginx 的 add_header 在 location 块里出现时会完全覆盖 server 块的同级指令（不是合并），如果你某个 location 里加过任何 add_header，记得把安全头在那儿也重复一份，或者统一挪到 include 文件里处处引用。这个坑的表现是“首页有安全头，图片目录的响应没有”，排查时先想它。

相关阅读：安全响应头是运营期的补强项。《从零建站第一步：技术栈选型总纲，别一上来就纠结框架》运营组里它和监控、更新同属低配高收益，总纲的路线图照走即可。

安全响应头补齐战：CSP、X-Frame-Options一次配到位

相关文章