Nginx如何配置才能通过Mozilla Observatory安全评分？完整配置指南

Mozilla Observatory是一个在线安全评估工具，它通过检测网站的HTTP响应头来给出安全评分，范围从F到A+。很多人第一次扫描自己的网站时往往会看到刺眼的F级评分，这并不意味着网站一定存在漏洞，但确实说明浏览器端缺少了一层重要的防护配置。本文以Nginx为例，详细讲解每一项安全头的作用、配置方法以及背后的安全逻辑。

理解Observatory的评分机制

Observatory并不是渗透测试工具，它只检查公开可见的HTTP响应头和部分服务行为，比如Cookie属性、TLS配置等。评分项目包括Content Security Policy、HTTP Strict Transport Security、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Cookies安全属性等十多项。每项权重不同，CSP和HSTS占比较高，这也是很多人配了几个基础头之后评分依然上不去的原因。

值得注意的是，Observatory的评分与实际安全风险并不完全等同。一个没有任何用户输入和敏感数据的静态站点，缺少这些头部的实际危害很有限。但如果站点涉及登录、支付等敏感操作，这些头部的缺失就可能在遭受点击劫持、中间人攻击、XSS注入时放大损失。因此配置这些头部，本质上是给浏览器下发一套防御指令，让浏览器主动帮助拦截部分攻击。

建议在动手配置前，先用自己的域名在Observatory上扫描一次，记录当前每一项的得分明细，这样配置完成后可以对比验证效果。Observatory扫描后会给出各项的具体提示，比想象中更友好。

核心安全头的Nginx配置

最常见的配置位置是server块或location块，使用add_header指令。下面给出一份较为完整的示例：

server {
    listen 443 ssl http2;
    server_name ippipp.com;

    # 强制HTTPS，包含子域名，有效期一年，允许预加载
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # 禁止浏览器猜测MIME类型
    add_header X-Content-Type-Options "nosniff" always;

    # 禁止被其他网站iframe嵌套
    add_header X-Frame-Options "DENY" always;

    # 控制Referer信息泄露
    add_header Referrer-Policy "no-referrer-when-downgrade" always;

    # 基础CSP策略
    add_header Content-Security-Policy "default-src 'self'" always;
}

这里有两个关键细节。第一是always参数，加上它之后，即使Nginx返回404、500等错误响应，安全头也会被附加，否则这些头只在正常响应中出现。第二是add_header的继承规则，如果location块中定义了任意一个add_header，那么server块中的所有add_header都会失效，这是Nginx的常见坑点。解决办法是在每个location块中重复完整的头部配置，或者统一使用include指令引入一个公共配置文件：

# /etc/nginx/snippets/security-headers.conf
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;

# 在server或location块中引用
# include snippets/security-headers.conf;

Cookies的属性也需要检查，Observatory会检测会话Cookie是否带有Secure、HttpOnly和SameSite标记。这些通常由后端应用设置，但如果后端不方便修改，可以用proxy_cookie_path或header修改模块在Nginx层补齐：

proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

CSP策略的渐进式收紧

CSP是Observatory评分中占比最高的项目之一，也是最容易把网站配坏的一项。上面示例中的default-src 'self'是最严格的基线策略，但如果网站引用了外部脚本、图片或内联样式，浏览器会直接阻止加载，页面可能瞬间白屏。

推荐的做法是先用report-only模式部署，让浏览器只上报违规项而不实际拦截，观察一段时间收集到的报告再逐步收紧：

add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report" always;

如果站点确实需要内联脚本或样式，尽量避免使用不安全的unsafe-inline，可以通过nonce方式给合法的内联代码签发一次性令牌。对于无法改造的遗留系统，至少把script-src和object-src限制清楚，这两项对XSS防护贡献最大。Observatory对CSP的评分有细致的分级，包含default-src且覆盖script-src的策略得分远高于零散的单项配置。

HSTS与TLS配置要点

HSTS头部告诉浏览器在指定时间内只通过HTTPS访问站点，即使用户手动输入HTTP地址或点击HTTP链接也会被浏览器内部重定向。enable preload的站点还可以加入浏览器的预加载列表，从首次访问起就强制HTTPS。需要注意的是，HSTS一旦下发就难以撤回，浏览器会缓存整个max-age周期，所以建议先用较小的max-age比如300秒试运行，确认全站HTTPS无死角后再调到一年。

启用HSTS的前提是TLS配置本身没有明显问题。Observatory会参考TLS相关检测结果，建议使用TLSv1.2及以上协议，禁用已知弱加密套件，并配置较新的证书：

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;

另外建议启用OCSP装订和HTTP到HTTPS的全局301重定向，把80端口的server块简化为一条return指令即可。

配置后的验证与持续维护

所有配置修改完成后，先用nginx -t检查语法，再平滑重载服务。随后可以用curl命令验证响应头是否如预期输出：

curl -sI https://ippipp.com | grep -i -E "strict|security|frame|referrer"

确认无误后重新到Observatory扫描一次。如果之前是F级，完成上述配置后通常可以达到A级。要冲A+，一般还需要提交HSTS Preload列表、配置更完善的CSP，以及处理其余细节项。

安全头配置不是一次性工作。当站点引入新的第三方服务、CDN或统计脚本时，CSP可能需要同步调整，建议把变更纳入发布流程。同时也可以考虑开启Observatory的持续监控功能，或用脚本定期扫描，一旦评分下降能够及时发现。把这些响应头当作网站的标准基础设施来维护，才能真正发挥浏览器端防护的价值。

NginxMozilla ObservatoryHTTP安全头修改时间：2026-09-04 15:44:02