说到 Nginx大家聊得最多的往往是高并发、反向代理、负载均衡、平滑升级这些性能向的话题。但我这几年帮别人排查线上问题发现一个更常见也更扎眼的现象很多站点的 Nginx 响应头几乎是裸奔的——没有 X-Content-Type-Options没有 CSP没有 HSTS甚至连 Server 版本号都挂在外面。说白了安全头这一块完全没人管。这篇文章想系统聊聊 Nginx 常用安全头每个头到底解决什么问题、在 Nginx 里怎么配、实际部署会踩哪些坑。适合刚接触 Web 安全的开发运维也适合想把现有 Nginx 配置补全的同学。我会把配置模板直接贴出来你复制过去改改就能用但更希望你看完明白每一行的含义别成了无脑抄配置。1. 安全头到底在防什么1.1 浏览器端的“安检员”HTTP 响应头里那些看似不起眼的字段其实扮演着浏览器安检员的角色。浏览器拿到 HTML、JS、图片这类资源后要不要执行、能不能进 iframe、请求有没有带 Referer、连接能不能降级成明文这些判断很大程度都取决于响应头里那几个安全开关。举个例子如果没有 X-Content-Type-Options: nosniff浏览器有时候会自作聪明地去“嗅探”文件真实类型。一个被上传的文本文件如果内容长得像 HTML浏览器就可能把它当页面渲染这种 MIME 混淆经常被用来绕过上传检测。再比如少了 X-Frame-Options 或 CSP 的 frame-ancestors你的支付页面、后台管理页就可能被恶意站点用 iframe 套进去配合透明遮罩做点击劫持用户点了哪里自己都不知道。安全头做的事情是把这类原本交给浏览器判断的“概率题”变成“送分题”。你明确告诉浏览器不许乱猜类型、不许有人套我页面、不信任任何外部来源的脚本。浏览器就乖乖照做攻击面自然就小了。1.2 为什么都在 Nginx 这层配很多框架自带安全头配置比如 Express 里的 helmet、Spring Security 的 headers 配置。但如果你用的是 Nginx 做网关或反代我强烈建议在 Nginx 这一层统一处理。原因很直接Nginx 是流量出口所有响应都要从这里经过。不管后面挂的是 Tomcat、PHP-FPM 还是 Node.js也不管是静态页面还是接口返回只要在 Nginx 配好安全头就能一刀切覆盖所有响应。上游应用如果有自己的安全头Nginx 的 add_header 还能和它们共存主动权在你手里。不过这里要留个心眼Nginx 的 add_header 存在继承陷阱后面有专门一节放雷。很多站点配置了半天只剩一两个头生效多半就是踩了继承规则的坑。2. 常用安全头逐个拆解先放一张速查表后面再逐个展开安全头核心作用常用取值X-Content-Type-Options禁止 MIME 类型嗅探nosniffX-Frame-Options禁止页面被 iframe 嵌入DENY / SAMEORIGINX-XSS-Protection旧浏览器 XSS 过滤器1; modeblockContent-Security-Policy内容来源白名单default-src self ...Strict-Transport-Security强制 HTTPS 访问max-age31536000Referrer-Policy控制 Referer 携带策略strict-origin-when-cross-originPermissions-Policy限制浏览器功能权限camera(), geolocation()Cache-Control控制页面/接口缓存no-store / no-cacheserver_tokens隐藏 Nginx 版本号off2.1 X-Content-Type-Options一个字节都不能错这个头的配置极其简单就一行add_header X-Content-Type-Options nosniff always;它告诉浏览器不要主动猜测资源的 Content-Type服务端说是什么就是什么。这能堵住一类很隐蔽的问题——存储型 XSS 或恶意文件上传后本来应该以纯文本或图片返回如果少了 nosniff浏览器可能会把内容当 HTML 去解析脚本就跟着执行了。我见过一个实际案例某个文件上传功能只校验了扩展名攻击者上传了一个后缀是.txt、内容却带着