第一次把安全扫描报告递给我的时候上面一长串红色标记基本都指向同一个地方——Nginx返回的HTTP响应头。CSP缺失、X-XSS-Protection未设置、点击劫持风险……看着挺吓人其实说白了就是几个响应头字段的事。这篇文章我就从零开始带你把最常见的10个Nginx安全响应头问题逐个捋一遍能配置的直接贴配置有坑的提前告诉你适合正在处理安全扫描报告、准备做等保合规加固或者单纯想把自己站点响应头补齐的运维和开发同学。1. 安全响应头是个什么东西整体思路与选型逻辑1.1 扫描工具为什么总给你报“漏洞”很多人第一次看到报告里写着“X-Frame-Options头缺失”、“CSP配置不完整”这类问题时第一反应是我的服务器是不是被黑了其实不是。这类问题多数是配置型风险不是入侵痕迹。浏览器在加载网页时服务器会在HTTP响应里附带一堆header字段比如常见的Content-Type、Set-Cookie。其中有一类特殊的header专门用来约束浏览器对当前页面的行为比如能不能被别的网站用iframe嵌入、是否允许执行内联脚本、跨域请求是否携带来源信息、要不要强制用HTTPS连接。这类header统称为安全响应头。扫描工具做的其实很简单它模拟浏览器请求你的页面看一眼返回的响应头列表没有检测到某个字段或字段值不够严格就记一条“漏洞”。所以修复思路也直接把该有的头加上把值配严谨报告就干净了。这个过程不需要改后端代码、不需要重构前端页面在Nginx这一层就能完成这也是为什么我强烈建议在网关层统一处理。1.2 为什么选Nginx这一层统一处理如果你的系统是几十个微服务每个服务都有自己的Web框架Spring Boot、Django、Express之类的那在每个应用里单独配安全头会疯掉改一处要发一轮版漏配一个服务扫描器照样报红。把安全头放在Nginx层本质上是做了一次治理层面的收敛——入口只有一个规则只写一份。Nginx配置安全头有天然优势它是反向代理所有进出流量都得经过它它可以用add_header指令给响应附加字段它支持include机制可以抽一个独立配置文件让多个server共用而且在代理场景下还能顺手处理后端返回的Set-Cookie安全属性。对于中小规模站点来说这一层已经能覆盖绝大多数安全扫描项。需要提前说明的是如果你的站点由云厂商的LB负载均衡直接暴露公网后面才接Nginx可能出现LB层响应头和Nginx层响应头不一致的现象。这时候要么在LB也配置同样的头要么确保只有Nginx作为唯一对外入口。实际操作中不少“配置了不生效”的诡异问题最后查下来都是前面多了层网关把头覆盖掉了。1.3 开工前的准备版本和基础配置检查开始动手之前先确认三件事Nginx版本。nginx -v看一下建议1.18以上老版本也有这些指令但新版本对proxy_cookie_flags这类指令支持更完整。决定配置粒度。建议单独建一个/etc/nginx/conf.d/security-headers.conf用include引到各server块里而不是直接改nginx.conf主文件方便后续维护和回滚。准备一个不改动业务代码的验证环境。配置完安全头后页面可能因为CSP太严格而样式全挂调试期间需要一个能从浏览器访问的测试地址。2. 逐个修复10个常见安全响应头核心细节拆解2.1 CSP最复杂也最容易被绕过的那个头CSP全称Content-Security-Policy它告诉浏览器“这个页面允许加载哪些来源的资源”。没有它你的页面如果被注入了一段恶意脚本浏览器会无条件执行因为没有任何约束。有了它就算攻击者注入成功了浏览器发现脚本来源不在白名单里直接拒绝执行。CSP是这10个头里配置难度最高的原因是它直接影响页面功能。随便给一个严格策略页面上的内联脚本、外部CDN、甚至base64图片都可能被拦。扫报告时常看到两种状态要么完全没有CSP要么CSP里写着default-src *形同虚设。一个典型且不太容易搞挂站点的起始策略是这样的add_header Content-Security-Policy default-src self; script-src self; style-src self; img-src self data:; connect-src self; object-src none; base-uri self; form-action self; frame-ancestors self always;拆开看关键点default-src self兜底策略所有没有单独指定的资源类型默认只允许加载同域名资源。script-src self只允许加载本站脚本。这是CSP里最敏感的一项如果前端有内联的script标签或eval调用就会直接白屏。style-src self限制样式来源。很多老项目页面里写了style...内联样式或者用JS动态插入CSS这个策略一上就会报警告。img-src self data:允许本站图片和data URL图片。base64小图在很多系统里都有不放开这个会出现图片显示不了的问题。frame-ancestors self和X-Frame-Options作用重叠但不完全一致现代浏览器优先认这个指令。在把这个策略加到生产环境之前建议先在测试环境开着浏览器DevTools的Console面板过一遍页面看有没有报错。CSP的拦截报错会明确写出“拒绝加载某某资源”照着报错补白名单就行。补充时不要图省事往script-src里加*加一次就等于把CSP的脚本保护全部废掉以后注入就拦不住了。2.2 X-Frame-Options 与 frame-ancestors防点击劫持点击劫持是个老问题了攻击者把目标网站放在一个透明的iframe里诱导用户点击伪装后的页面按钮实际上点的是目标网站上的操作按钮。要防这一招最直接的办法就是告诉浏览器这个页面不允许被嵌入iframe。X-Frame-Options有三个可选值DENY任何情况下都不允许被嵌入包括同域名页面也不行。SAMEORIGIN只允许同域名页面嵌入自己。ALLOW-FROM uri允许指定URI嵌入但这个值兼容性不好基本不建议用。配置很简单add_header X-Frame-Options SAMEORIGIN always;同时建议在CSP里带上frame-ancestors self因为现代浏览器已经把frame嵌入控制权移交给了CSP的frame-ancestors指令两个同时设置可以兼顾老浏览器和新浏览器。这里面有一个非常现实的坑如果你们有支付跳转后回到第三方页面、或者某些营销页面需要嵌入在别人的站点里DENY或SAMEORIGIN会直接导致页面空白。遇到这种情况不要硬开可以在对应location用add_header X-Frame-Options ALLOW-FROM ...做个例外或者权衡后通过产品方案规避。这是安全性和业务需求打架最典型的案例。2.3 X-Content-Type-Options 和 X-XSS-Protection这两个头经常被扫描器一起报因为都算老牌安全头配置也简单放在一起讲。X-Content-Type-Options只有一个有效值就是阻止浏览器对响应内容做MIME类型猜测。场景是这样的你上传了一个伪装成图片的HTML文件正常情况下服务器返回Content-Type: image/png浏览器就会按图片处理。但有些浏览器会“体贴”地去嗅探实际内容发现内容是HTML于是按HTML渲染——一个存储型XSS就出来了。加了这行配置浏览器就老实按声明的类型处理add_header X-Content-Type-Options nosniff always;X-XSS-Protection是另一个老面孔但它的处境比较尴尬。早年浏览器自带XSS过滤器这个头用来控制过滤器的开关常见写法是1; modeblock意思是开启过滤并阻止页面渲染。但现在主流浏览器陆续把内置XSS审计器移除了继续设置这个头更多是“给扫描器和等保检查看”的意义。在实际项目里如果你的CSP已经配置到位X-XSS-Protection不是关键防线但如果客户的安全基线明确要求看到这个头就按扫描器的期望配置add_header X-XSS-Protection 1; modeblock always;有少数扫描器反而建议设为0因为浏览器实现里曾出现过过滤器绕过导致漏洞的奇技淫巧。我的建议是以你的安全扫描报告为准报告要什么就给什么同时把主要精力放在CSP上。2.4 HSTS开之前想清楚12个月HSTS全称Strict-Transport-Security作用很简单浏览器访问过一次启用了HSTS的HTTPS站点后之后就强制使用HTTPS连接不再允许降级到HTTP。它能有效防止中间人把HTTPS降级成HTTP再抓包。add_header Strict-Transport-Security max-age31536000; includeSubDomains always;这里的max-age31536000是秒数正好是一年。一个小技巧第一次上线时建议先用小值比如max-age300观察几天确认整条链路包括子域、CDN、静态资源都能正常走HTTPS再改成长期值。为什么因为HSTS的强制是有“记忆”的浏览器把这个策略记住了过期之前你想撤回都撤不回来。真遇到证书到期、临时要退回HTTP调试的场景HSTS会把你死死按在HTTPS上。再说说includeSubDomains它的意思是这个策略对当前域名的所有子域生效。如果你的某个子域还没有配HTTPS证书或者一直用HTTP对外提供服务这个参数一加那个子域基本就废了——用户会被强制跳转HTTPS然后得到证书错误。所以加之前盘一遍所有子域的HTTPS覆盖情况别被这个参数背刺。2.5 Referrer-Policy管好你的来源信息浏览器在页面发起资源请求时默认会在Referer头里带上来源页面的完整URL包括路径、参数、甚至某些敏感信息。如果你的页面被第三方引用了或者页面里引用了第三方统计脚本来源地址里的参数可能就泄露了。Referrer-Policy这个头就是用来控制这些来源信息到底能带出去多少。推荐使用的生产配置add_header Referrer-Policy strict-origin-when-cross-origin always;这个值的意思是同源请求带完整URL跨源请求只带来源的源信息协议域名端口不带路径和参数从HTTPS页面跳转到HTTP时完全不发送Referrer。这是目前兼容性和安全性平衡最好的方案不需要过度收紧到no-referrer否则会影响正常的流量统计和防盗链判断。2.6 Permissions-Policy把浏览器能力开关收回来Permissions-Policy旧名叫Feature-Policy用来限制页面可以使用哪些浏览器能力比如摄像头、麦克风、地理位置、传感器、弹窗等。如果一个业务页面根本用不到摄像头却允许页面里的任何脚本包括被注入的脚本调起摄像头这是白白扩大了攻击面。一个保险的配置add_header Permissions-Policy camera(), microphone(), geolocation() always;括号为空表示禁止页面对该能力的调用。如果你有业务确实要调用其中某项比如在线考试需要开启摄像头再单独给对应页面放开权限比如camera(self)只允许同源页面使用。需要有一个认识这个头是“按页面功能最小化”的思路不是一刀切。2.7 Server信息泄露、缓存控制和Cookie安全属性扫描报告里还有几项经常出现但不是纯响应头概念的项放在一起解决。第一个是Server头信息暴露。Nginx默认在响应里带Server: nginx/1.xx.x暴露了服务器软件类型和版本号等于告诉攻击者可以重点针对这个版本找已知漏洞。解决办法不是完全隐藏Server头旧版Nginx基本藏不掉而是关掉版本号server_tokens off;这样返回的Server头会变成nginx不带版本号。第二个是Cookie的Secure、HttpOnly、SameSite属性。严格说这属于Set-Cookie响应头的属性配置Nginx这边不能直接用add_header给Set-Cookie追加属性但可以用代理指令处理后端返回的Cookie。以Nginx 1.19.3为例proxy_cookie_flags default httponly samesitelax secure;这三个属性的含义分别是Cookie只能通过HTTP/HTTPS传输、脚本无法读取跨站请求时同站点限制Cookie只通过HTTPS传输。如果你们的后端服务是Java或Node直接返回Set-Cookie这一行统一帮你在Nginx层补齐属性不用改业务代码。第三个是缓存控制。登录后页面如果被浏览器或中间缓存代理缓存其他用户可能直接读到上一个用户的数据。建议对包含敏感信息的location配置add_header Cache-Control no-store, no-cache, must-revalidate; add_header Pragma no-cache;注意add_header本身不默认拦截上游的缓存头配置但显式指定后优先级更高。2.8 十个头的配置速查汇总这一节最后整理成一张速查表方便对照检查。配置时建议按这个表统一风格不要一会加引号一会不加格式越统一后续排查越省事。响应头推荐配置值备注Content-Security-Policydefault-src self; script-src self; style-src self; img-src self data:; object-src none; frame-ancestors self根据站点实际资源补充白名单X-Frame-OptionsSAMEORIGIN老浏览器兜底新浏览器走CSP frame-ancestorsX-Content-Type-Optionsnosniff无脑加X-XSS-Protection1; modeblock以客户扫描要求为准Strict-Transport-Securitymax-age31536000; includeSubDomains首次上线用小max-ageReferrer-Policystrict-origin-when-cross-origin安全与统计平衡Permissions-Policycamera(), microphone(), geolocation()按业务能力放开Server版本号server_tokens off;隐藏Nginx版本号Set-Cookie属性proxy_cookie_flags default httponly samesitelax secure;需要代理场景Cache-Controlno-store, no-cache, must-revalidate用于敏感页面location3. 实操过程搭一份开箱即用的Nginx安全响应头配置3.1 建立独立配置文件的工程化思路坚决不建议把这些add_header直接散落在nginx.conf或各个server块里。理由很实际你很快会需要在同一套配置上叠加或删减散落写法让你改一处要全局搜索而且add_header的继承规则极容易因为位置不同产生诡异行为。我现在的做法是建一个/etc/nginx/conf.d/security.confmkdir -p /etc/nginx/conf.d touch /etc/nginx/conf.d/security.conf然后在需要加安全头的server块里include进来server { listen 443 ssl; server_name example.com; include conf.d/security.conf; # 其他配置... }这样做的最大好处是新接一个站点只需要在server块里加一行include10个安全头的加固就全有了。对于多站点环境维护一套、处处生效效率高不少。代价是如果你个别站点的CSP白名单差异很大include同一套配置就不合适了。这种情况建议把公共的安全头X-Frame-Options、nosniff、Referrer-Policy等放公共配置文件把CSP单独拆成csp.conf按需include灵活得多。3.2 完整配置内容逐段说明下面给一份可用的security.conf标注几个关键点add_header Content-Security-Policy default-src self; script-src self; style-src self; img-src self data:; font-src self data:; connect-src self; object-src none; frame-ancestors self; base-uri self; form-action self always; add_header X-Frame-Options SAMEORIGIN always; add_header X-Content-Type-Options nosniff always; add_header X-XSS-Protection 1; modeblock always; add_header Strict-Transport-Security max-age31536000; includeSubDomains always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header Permissions-Policy camera(), microphone(), geolocation() always; server_tokens off;逐行说几个值得注意的细节每个add_header后面都带了always参数。这个参数是必须的不加的话默认只在响应码为200、201、204、206、301、302、303、304、307、308时才输出头404、500这类错误响应头统统不带。上次有人配置了半天扫描器还是报404页面缺头就是因为漏了always。CSP里加了font-src self data:是因为很多网站用的字体图标是data字体或本地字体文件不放开会提示字体加载失败。object-src none禁止object、embed等老标签加载插件。这类标签是历史上挂马重灾区建议一律禁掉。base-uri self限制base标签只能指向本站域名防止攻击者改base后把相对URL全部劫持到恶意域名去。form-action self限制表单只能提交到本站防止钓鱼表单场景。这份配置的CSP不是最严格的有些报告要求upgrade-insecure-requests、block-all-mixed-content这种追加指令但它是“能上线不搞挂页面”的一个平衡点。严格程度可以看你们安全团队要求逐步加不建议一步到位。3.3 多server、多场景下的生效细节这里必须讲一下Nginx add_header的继承规则不搞清楚这个配置出问题你连原因都找不到。规则一句话就能说清一个块里如果出现任意一条add_header指令那么这个块会忘掉所有从上一级继承来的add_header只保留自己块内写的那些。举个例子server { include conf.d/security.conf; location /api/ { add_header Cache-Control no-store; } }这个配置里location /api/因为自己写了add_header Cache-Control所以这个location返回的所有响应都只有Cache-Control没有CSP、没有X-Frame-Options什么都没有。你查响应头时会发现安全头全丢了。解决方式有三个在location里重复include公共配置location /api/ { include conf.d/security.conf; add_header Cache-Control no-store; }把公共配置提取成一个Nginx片段用include在需要的地方重复引用。靠include可以规避继承问题因为每次include都是往当前块里平铺一层指令。给Java系/Node系后端代理时如果后端自己会设置CSP注意add_header不会覆盖后端返回的同名头除非用proxy_hide_header先把上游的响应头隐藏掉再add_header。实际排查时遇到过Nginx配了CSP后端服务自己也写了个宽松CSP浏览器最终认了后端的。这种情况不要慌在location里加proxy_hide_header Content-Security-Policy;再配合add_header强制统一。另外静态资源location可以区分对待。图片、CSS、JS这类响应不需要Cookie、不需要CSP你可以只在静态location里精简配置减少响应头体积。但精简的前提是你很清楚哪些安全头是必须全局一致的比如HSTS、nosniff否则不如全部统一。3.4 验证生效一条命令和一个浏览器面板配置完毕后先别急着让安全扫描器来查自己先验一轮。验证第一步用curl看响应头curl -I https://example.com/-I只发HEAD请求查看响应头。如果服务器对HEAD支持不好就换curl -s -D - -o /dev/null https://example.com/同样只看响应头。重点检查以下几点Content-Security-Policy、X-Frame-Options、X-Content-Type-Options等都在。Server头不带版本号。每个头后面是不是有always生效的行为表现可以用一个不存在的路径测一下404curl -I https://example.com/not-exist如果404也带这些头说明always生效了。验证第二步用浏览器打开页面上线前的测试环境打开DevTools的Network面板随便点几个接口看Response Headers再切到Console看有没有CSP相关的警告或报错。这一步比扫描器有价值多了——它直接告诉你页面功能有没有被安全头误伤。如果页面里有用到第三方上报脚本、地图SDK、客服组件务必一个个页面点过来。CSP和这些外部服务是冲突高发区尤其远程客服和第三方埋点几乎都需要在script-src白名单里补域名。4. 实操现场常见问题与排查技巧实录4.1 add_header 不生效或者404才生效这个问题十个人有八个人会遇到方向基本是三个一是漏了always。响应码不在默认列表里头就不输出。这事的发生率极高扫描器测404页面缺头就是典型的症状。二是location里自己写了add_header把server层安全头全冲掉了。这是Nginx继承规则的锅按前面说的方法在location里重新include或重复add_header即可。三是上游有代理把响应头去掉了。排查方法是拿curl直接请求Nginx的监听端口绕过上层负载均衡看response。如果直连Nginx有头、走公网没有问题就在前面的网关。4.2 CSP一开样式全挂这是把CSP从无到有配置时最常见的事故。Nginx配置完刷新页面发现白屏或者错乱Console里一排报错Refused to apply inline style because it violates the following Content Security Policy directive。原因基本是页面里有内联的style属性或style标签而策略里style-src self不允许内联样式。处理顺序我建议这样排先把页面里的内联样式、内联脚本尽量外链化这是最干净的办法如果历史遗留太多确实改不动再考虑在style-src里加unsafe-inline——但要清醒加了这个等于CSP对样式注入的限制形同虚设属于妥协方案。还有一个常见的误伤来源是前端框架运行时注入样式。有些组件库会在运行时把样式写到style标签里不是你想外链就能外链的。碰到这种可以考虑给相关页面单独配一条宽松些的CSP别让全站CSP因为一个页面被拉低。4.3 HSTS开了回不去这个坑属于“配置容易、回滚难”的典型。具体现象加了HSTS头后调试环境或者测试域名因为证书过期、或临时需要用HTTP访问发现浏览器怎么都不肯走HTTP一直在HTTPS报错页面上转。原因就是前面说的“浏览器记住了HSTS策略”。解决思路有几个第一次上线用max-age60这种短时间观察确认没问题再改一年。这是最推荐的稳妥路线。测试时用无痕窗口或者临时换一个浏览器内核避开本地记忆的HSTS策略。如果确实要走HTTP调试可以在浏览器地址栏手动输入http://试试部分浏览器会在HSTS enforce下自动跳到HTTPS这个行为没法通过服务端配置临时关闭。如果访问的是子域还受includeSubDomains约束那整个域的HTTP访问基本被锁死。4.4 上游后端把安全头覆盖了代理场景下Nginx的add_header行为不会替换上游返回的同名头。比如后端Java服务在代码里设置了X-Frame-Options: ALLOWALLNginx层配的SAMEORIGIN根本不会生效。响应头以第一次出现的值为准实际是浏览器读取时通常取最先出现的或者更准确说是合并处理时看代理如何拼接。要强制统一Nginx层的安全头可以用proxy_hide_header先隐藏上游的同名头location / { proxy_hide_header Content-Security-Policy; proxy_hide_header X-Frame-Options; proxy_hide_header Strict-Transport-Security; include conf.d/security.conf; proxy_pass http://backend; }注意顺序proxy_hide_header要在add_header之前逻辑是先剥掉后端的再补自己的。这也是为什么所有add_header统一写在配置前面更不容易踩坑。4.5 安全头多但页面加载变慢多半是心理作用配置完所有安全头有人用curl -w对比响应时间发现加了几个头之后慢了几毫秒开始担心性能。实际上HTTP头增加几十字节对网络传输影响微乎其微真正的影响来自CSP对浏览器加载资源的限制导致的重试或阻塞——比如CSP白名单配错了浏览器先尝试加载再被拦截白等一次资源超时。这就不是性能问题而是配置错误导致的资源加载失败。真为性能考虑给静态资源单独配location并放行缓存给动态接口沿用全局安全头。安全头本身不是性能瓶颈别在排查方向上百忙一场。4.6 常见问题速查表把上面这些整理成一个速查表方便直接查现象原因处理404页面不含安全头add_header漏了always所有安全头加上alwayslocation接口缺安全头location里自己的add_header冲掉了server层include公共配置或在location重复add_header页面白屏并报样式拒绝CSP的style-src不允许内联样式样式外链化或单独放宽上游响应头覆盖Nginx配置后端代码设置了同名响应头proxy_hide_header先隐藏再add_headercookies不带Secure/HttpOnly应用层Cookie报文直接设置proxy_cookie_flags统一追加属性HSTS生效后无法退回HTTP浏览器已记住长max-age首次配置用短max-age加载外部资源全部被拦CSP白名单未包含第三方域名在对应指令里追加来源域名最后再分享一个小技巧我自己的习惯是每配完一批安全头就用curl把主域名和几个核心API路径全部扫一遍响应头再开浏览器过一遍主流程页面双管齐下。安全报告上的10个“漏洞”其实用不了一天就能填完真正的功夫在填完之后CSP别一次拉太紧、HSTS别一开始就一年、add_header别随手写在location里。这套配置跑稳之后后面新接入的站点直接照搬五分钟一个站。先跑起来再慢慢收紧比一次性追求完美策略靠谱得多。 
长河君 · 2026/10/19 10:19:52 · 阅读 1.2k Nginx安全响应头加固实战：10个常见配置项与排坑指南
第一次把安全扫描报告递给我的时候上面一长串红色标记基本都指向同一个地方——Nginx返回的HTTP响应头。CSP缺失、X-XSS-Protection未设置、点击劫持风险……看着挺吓人其实说白了就是几个响应头字段的事。这篇文章我就从零开始带你把最常见的10个Nginx安全响应头问题逐个捋一遍能配置的直接贴配置有坑的提前告诉你适合正在处理安全扫描报告、准备做等保合规加固或者单纯想把自己站点响应头补齐的运维和开发同学。1. 安全响应头是个什么东西整体思路与选型逻辑1.1 扫描工具为什么总给你报“漏洞”很多人第一次看到报告里写着“X-Frame-Options头缺失”、“CSP配置不完整”这类问题时第一反应是我的服务器是不是被黑了其实不是。这类问题多数是配置型风险不是入侵痕迹。浏览器在加载网页时服务器会在HTTP响应里附带一堆header字段比如常见的Content-Type、Set-Cookie。其中有一类特殊的header专门用来约束浏览器对当前页面的行为比如能不能被别的网站用iframe嵌入、是否允许执行内联脚本、跨域请求是否携带来源信息、要不要强制用HTTPS连接。这类header统称为安全响应头。扫描工具做的其实很简单它模拟浏览器请求你的页面看一眼返回的响应头列表没有检测到某个字段或字段值不够严格就记一条“漏洞”。所以修复思路也直接把该有的头加上把值配严谨报告就干净了。这个过程不需要改后端代码、不需要重构前端页面在Nginx这一层就能完成这也是为什么我强烈建议在网关层统一处理。1.2 为什么选Nginx这一层统一处理如果你的系统是几十个微服务每个服务都有自己的Web框架Spring Boot、Django、Express之类的那在每个应用里单独配安全头会疯掉改一处要发一轮版漏配一个服务扫描器照样报红。把安全头放在Nginx层本质上是做了一次治理层面的收敛——入口只有一个规则只写一份。Nginx配置安全头有天然优势它是反向代理所有进出流量都得经过它它可以用add_header指令给响应附加字段它支持include机制可以抽一个独立配置文件让多个server共用而且在代理场景下还能顺手处理后端返回的Set-Cookie安全属性。对于中小规模站点来说这一层已经能覆盖绝大多数安全扫描项。需要提前说明的是如果你的站点由云厂商的LB负载均衡直接暴露公网后面才接Nginx可能出现LB层响应头和Nginx层响应头不一致的现象。这时候要么在LB也配置同样的头要么确保只有Nginx作为唯一对外入口。实际操作中不少“配置了不生效”的诡异问题最后查下来都是前面多了层网关把头覆盖掉了。1.3 开工前的准备版本和基础配置检查开始动手之前先确认三件事Nginx版本。nginx -v看一下建议1.18以上老版本也有这些指令但新版本对proxy_cookie_flags这类指令支持更完整。决定配置粒度。建议单独建一个/etc/nginx/conf.d/security-headers.conf用include引到各server块里而不是直接改nginx.conf主文件方便后续维护和回滚。准备一个不改动业务代码的验证环境。配置完安全头后页面可能因为CSP太严格而样式全挂调试期间需要一个能从浏览器访问的测试地址。2. 逐个修复10个常见安全响应头核心细节拆解2.1 CSP最复杂也最容易被绕过的那个头CSP全称Content-Security-Policy它告诉浏览器“这个页面允许加载哪些来源的资源”。没有它你的页面如果被注入了一段恶意脚本浏览器会无条件执行因为没有任何约束。有了它就算攻击者注入成功了浏览器发现脚本来源不在白名单里直接拒绝执行。CSP是这10个头里配置难度最高的原因是它直接影响页面功能。随便给一个严格策略页面上的内联脚本、外部CDN、甚至base64图片都可能被拦。扫报告时常看到两种状态要么完全没有CSP要么CSP里写着default-src *形同虚设。一个典型且不太容易搞挂站点的起始策略是这样的add_header Content-Security-Policy default-src self; script-src self; style-src self; img-src self data:; connect-src self; object-src none; base-uri self; form-action self; frame-ancestors self always;拆开看关键点default-src self兜底策略所有没有单独指定的资源类型默认只允许加载同域名资源。script-src self只允许加载本站脚本。这是CSP里最敏感的一项如果前端有内联的script标签或eval调用就会直接白屏。style-src self限制样式来源。很多老项目页面里写了style...内联样式或者用JS动态插入CSS这个策略一上就会报警告。img-src self data:允许本站图片和data URL图片。base64小图在很多系统里都有不放开这个会出现图片显示不了的问题。frame-ancestors self和X-Frame-Options作用重叠但不完全一致现代浏览器优先认这个指令。在把这个策略加到生产环境之前建议先在测试环境开着浏览器DevTools的Console面板过一遍页面看有没有报错。CSP的拦截报错会明确写出“拒绝加载某某资源”照着报错补白名单就行。补充时不要图省事往script-src里加*加一次就等于把CSP的脚本保护全部废掉以后注入就拦不住了。2.2 X-Frame-Options 与 frame-ancestors防点击劫持点击劫持是个老问题了攻击者把目标网站放在一个透明的iframe里诱导用户点击伪装后的页面按钮实际上点的是目标网站上的操作按钮。要防这一招最直接的办法就是告诉浏览器这个页面不允许被嵌入iframe。X-Frame-Options有三个可选值DENY任何情况下都不允许被嵌入包括同域名页面也不行。SAMEORIGIN只允许同域名页面嵌入自己。ALLOW-FROM uri允许指定URI嵌入但这个值兼容性不好基本不建议用。配置很简单add_header X-Frame-Options SAMEORIGIN always;同时建议在CSP里带上frame-ancestors self因为现代浏览器已经把frame嵌入控制权移交给了CSP的frame-ancestors指令两个同时设置可以兼顾老浏览器和新浏览器。这里面有一个非常现实的坑如果你们有支付跳转后回到第三方页面、或者某些营销页面需要嵌入在别人的站点里DENY或SAMEORIGIN会直接导致页面空白。遇到这种情况不要硬开可以在对应location用add_header X-Frame-Options ALLOW-FROM ...做个例外或者权衡后通过产品方案规避。这是安全性和业务需求打架最典型的案例。2.3 X-Content-Type-Options 和 X-XSS-Protection这两个头经常被扫描器一起报因为都算老牌安全头配置也简单放在一起讲。X-Content-Type-Options只有一个有效值就是阻止浏览器对响应内容做MIME类型猜测。场景是这样的你上传了一个伪装成图片的HTML文件正常情况下服务器返回Content-Type: image/png浏览器就会按图片处理。但有些浏览器会“体贴”地去嗅探实际内容发现内容是HTML于是按HTML渲染——一个存储型XSS就出来了。加了这行配置浏览器就老实按声明的类型处理add_header X-Content-Type-Options nosniff always;X-XSS-Protection是另一个老面孔但它的处境比较尴尬。早年浏览器自带XSS过滤器这个头用来控制过滤器的开关常见写法是1; modeblock意思是开启过滤并阻止页面渲染。但现在主流浏览器陆续把内置XSS审计器移除了继续设置这个头更多是“给扫描器和等保检查看”的意义。在实际项目里如果你的CSP已经配置到位X-XSS-Protection不是关键防线但如果客户的安全基线明确要求看到这个头就按扫描器的期望配置add_header X-XSS-Protection 1; modeblock always;有少数扫描器反而建议设为0因为浏览器实现里曾出现过过滤器绕过导致漏洞的奇技淫巧。我的建议是以你的安全扫描报告为准报告要什么就给什么同时把主要精力放在CSP上。2.4 HSTS开之前想清楚12个月HSTS全称Strict-Transport-Security作用很简单浏览器访问过一次启用了HSTS的HTTPS站点后之后就强制使用HTTPS连接不再允许降级到HTTP。它能有效防止中间人把HTTPS降级成HTTP再抓包。add_header Strict-Transport-Security max-age31536000; includeSubDomains always;这里的max-age31536000是秒数正好是一年。一个小技巧第一次上线时建议先用小值比如max-age300观察几天确认整条链路包括子域、CDN、静态资源都能正常走HTTPS再改成长期值。为什么因为HSTS的强制是有“记忆”的浏览器把这个策略记住了过期之前你想撤回都撤不回来。真遇到证书到期、临时要退回HTTP调试的场景HSTS会把你死死按在HTTPS上。再说说includeSubDomains它的意思是这个策略对当前域名的所有子域生效。如果你的某个子域还没有配HTTPS证书或者一直用HTTP对外提供服务这个参数一加那个子域基本就废了——用户会被强制跳转HTTPS然后得到证书错误。所以加之前盘一遍所有子域的HTTPS覆盖情况别被这个参数背刺。2.5 Referrer-Policy管好你的来源信息浏览器在页面发起资源请求时默认会在Referer头里带上来源页面的完整URL包括路径、参数、甚至某些敏感信息。如果你的页面被第三方引用了或者页面里引用了第三方统计脚本来源地址里的参数可能就泄露了。Referrer-Policy这个头就是用来控制这些来源信息到底能带出去多少。推荐使用的生产配置add_header Referrer-Policy strict-origin-when-cross-origin always;这个值的意思是同源请求带完整URL跨源请求只带来源的源信息协议域名端口不带路径和参数从HTTPS页面跳转到HTTP时完全不发送Referrer。这是目前兼容性和安全性平衡最好的方案不需要过度收紧到no-referrer否则会影响正常的流量统计和防盗链判断。2.6 Permissions-Policy把浏览器能力开关收回来Permissions-Policy旧名叫Feature-Policy用来限制页面可以使用哪些浏览器能力比如摄像头、麦克风、地理位置、传感器、弹窗等。如果一个业务页面根本用不到摄像头却允许页面里的任何脚本包括被注入的脚本调起摄像头这是白白扩大了攻击面。一个保险的配置add_header Permissions-Policy camera(), microphone(), geolocation() always;括号为空表示禁止页面对该能力的调用。如果你有业务确实要调用其中某项比如在线考试需要开启摄像头再单独给对应页面放开权限比如camera(self)只允许同源页面使用。需要有一个认识这个头是“按页面功能最小化”的思路不是一刀切。2.7 Server信息泄露、缓存控制和Cookie安全属性扫描报告里还有几项经常出现但不是纯响应头概念的项放在一起解决。第一个是Server头信息暴露。Nginx默认在响应里带Server: nginx/1.xx.x暴露了服务器软件类型和版本号等于告诉攻击者可以重点针对这个版本找已知漏洞。解决办法不是完全隐藏Server头旧版Nginx基本藏不掉而是关掉版本号server_tokens off;这样返回的Server头会变成nginx不带版本号。第二个是Cookie的Secure、HttpOnly、SameSite属性。严格说这属于Set-Cookie响应头的属性配置Nginx这边不能直接用add_header给Set-Cookie追加属性但可以用代理指令处理后端返回的Cookie。以Nginx 1.19.3为例proxy_cookie_flags default httponly samesitelax secure;这三个属性的含义分别是Cookie只能通过HTTP/HTTPS传输、脚本无法读取跨站请求时同站点限制Cookie只通过HTTPS传输。如果你们的后端服务是Java或Node直接返回Set-Cookie这一行统一帮你在Nginx层补齐属性不用改业务代码。第三个是缓存控制。登录后页面如果被浏览器或中间缓存代理缓存其他用户可能直接读到上一个用户的数据。建议对包含敏感信息的location配置add_header Cache-Control no-store, no-cache, must-revalidate; add_header Pragma no-cache;注意add_header本身不默认拦截上游的缓存头配置但显式指定后优先级更高。2.8 十个头的配置速查汇总这一节最后整理成一张速查表方便对照检查。配置时建议按这个表统一风格不要一会加引号一会不加格式越统一后续排查越省事。响应头推荐配置值备注Content-Security-Policydefault-src self; script-src self; style-src self; img-src self data:; object-src none; frame-ancestors self根据站点实际资源补充白名单X-Frame-OptionsSAMEORIGIN老浏览器兜底新浏览器走CSP frame-ancestorsX-Content-Type-Optionsnosniff无脑加X-XSS-Protection1; modeblock以客户扫描要求为准Strict-Transport-Securitymax-age31536000; includeSubDomains首次上线用小max-ageReferrer-Policystrict-origin-when-cross-origin安全与统计平衡Permissions-Policycamera(), microphone(), geolocation()按业务能力放开Server版本号server_tokens off;隐藏Nginx版本号Set-Cookie属性proxy_cookie_flags default httponly samesitelax secure;需要代理场景Cache-Controlno-store, no-cache, must-revalidate用于敏感页面location3. 实操过程搭一份开箱即用的Nginx安全响应头配置3.1 建立独立配置文件的工程化思路坚决不建议把这些add_header直接散落在nginx.conf或各个server块里。理由很实际你很快会需要在同一套配置上叠加或删减散落写法让你改一处要全局搜索而且add_header的继承规则极容易因为位置不同产生诡异行为。我现在的做法是建一个/etc/nginx/conf.d/security.confmkdir -p /etc/nginx/conf.d touch /etc/nginx/conf.d/security.conf然后在需要加安全头的server块里include进来server { listen 443 ssl; server_name example.com; include conf.d/security.conf; # 其他配置... }这样做的最大好处是新接一个站点只需要在server块里加一行include10个安全头的加固就全有了。对于多站点环境维护一套、处处生效效率高不少。代价是如果你个别站点的CSP白名单差异很大include同一套配置就不合适了。这种情况建议把公共的安全头X-Frame-Options、nosniff、Referrer-Policy等放公共配置文件把CSP单独拆成csp.conf按需include灵活得多。3.2 完整配置内容逐段说明下面给一份可用的security.conf标注几个关键点add_header Content-Security-Policy default-src self; script-src self; style-src self; img-src self data:; font-src self data:; connect-src self; object-src none; frame-ancestors self; base-uri self; form-action self always; add_header X-Frame-Options SAMEORIGIN always; add_header X-Content-Type-Options nosniff always; add_header X-XSS-Protection 1; modeblock always; add_header Strict-Transport-Security max-age31536000; includeSubDomains always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header Permissions-Policy camera(), microphone(), geolocation() always; server_tokens off;逐行说几个值得注意的细节每个add_header后面都带了always参数。这个参数是必须的不加的话默认只在响应码为200、201、204、206、301、302、303、304、307、308时才输出头404、500这类错误响应头统统不带。上次有人配置了半天扫描器还是报404页面缺头就是因为漏了always。CSP里加了font-src self data:是因为很多网站用的字体图标是data字体或本地字体文件不放开会提示字体加载失败。object-src none禁止object、embed等老标签加载插件。这类标签是历史上挂马重灾区建议一律禁掉。base-uri self限制base标签只能指向本站域名防止攻击者改base后把相对URL全部劫持到恶意域名去。form-action self限制表单只能提交到本站防止钓鱼表单场景。这份配置的CSP不是最严格的有些报告要求upgrade-insecure-requests、block-all-mixed-content这种追加指令但它是“能上线不搞挂页面”的一个平衡点。严格程度可以看你们安全团队要求逐步加不建议一步到位。3.3 多server、多场景下的生效细节这里必须讲一下Nginx add_header的继承规则不搞清楚这个配置出问题你连原因都找不到。规则一句话就能说清一个块里如果出现任意一条add_header指令那么这个块会忘掉所有从上一级继承来的add_header只保留自己块内写的那些。举个例子server { include conf.d/security.conf; location /api/ { add_header Cache-Control no-store; } }这个配置里location /api/因为自己写了add_header Cache-Control所以这个location返回的所有响应都只有Cache-Control没有CSP、没有X-Frame-Options什么都没有。你查响应头时会发现安全头全丢了。解决方式有三个在location里重复include公共配置location /api/ { include conf.d/security.conf; add_header Cache-Control no-store; }把公共配置提取成一个Nginx片段用include在需要的地方重复引用。靠include可以规避继承问题因为每次include都是往当前块里平铺一层指令。给Java系/Node系后端代理时如果后端自己会设置CSP注意add_header不会覆盖后端返回的同名头除非用proxy_hide_header先把上游的响应头隐藏掉再add_header。实际排查时遇到过Nginx配了CSP后端服务自己也写了个宽松CSP浏览器最终认了后端的。这种情况不要慌在location里加proxy_hide_header Content-Security-Policy;再配合add_header强制统一。另外静态资源location可以区分对待。图片、CSS、JS这类响应不需要Cookie、不需要CSP你可以只在静态location里精简配置减少响应头体积。但精简的前提是你很清楚哪些安全头是必须全局一致的比如HSTS、nosniff否则不如全部统一。3.4 验证生效一条命令和一个浏览器面板配置完毕后先别急着让安全扫描器来查自己先验一轮。验证第一步用curl看响应头curl -I https://example.com/-I只发HEAD请求查看响应头。如果服务器对HEAD支持不好就换curl -s -D - -o /dev/null https://example.com/同样只看响应头。重点检查以下几点Content-Security-Policy、X-Frame-Options、X-Content-Type-Options等都在。Server头不带版本号。每个头后面是不是有always生效的行为表现可以用一个不存在的路径测一下404curl -I https://example.com/not-exist如果404也带这些头说明always生效了。验证第二步用浏览器打开页面上线前的测试环境打开DevTools的Network面板随便点几个接口看Response Headers再切到Console看有没有CSP相关的警告或报错。这一步比扫描器有价值多了——它直接告诉你页面功能有没有被安全头误伤。如果页面里有用到第三方上报脚本、地图SDK、客服组件务必一个个页面点过来。CSP和这些外部服务是冲突高发区尤其远程客服和第三方埋点几乎都需要在script-src白名单里补域名。4. 实操现场常见问题与排查技巧实录4.1 add_header 不生效或者404才生效这个问题十个人有八个人会遇到方向基本是三个一是漏了always。响应码不在默认列表里头就不输出。这事的发生率极高扫描器测404页面缺头就是典型的症状。二是location里自己写了add_header把server层安全头全冲掉了。这是Nginx继承规则的锅按前面说的方法在location里重新include或重复add_header即可。三是上游有代理把响应头去掉了。排查方法是拿curl直接请求Nginx的监听端口绕过上层负载均衡看response。如果直连Nginx有头、走公网没有问题就在前面的网关。4.2 CSP一开样式全挂这是把CSP从无到有配置时最常见的事故。Nginx配置完刷新页面发现白屏或者错乱Console里一排报错Refused to apply inline style because it violates the following Content Security Policy directive。原因基本是页面里有内联的style属性或style标签而策略里style-src self不允许内联样式。处理顺序我建议这样排先把页面里的内联样式、内联脚本尽量外链化这是最干净的办法如果历史遗留太多确实改不动再考虑在style-src里加unsafe-inline——但要清醒加了这个等于CSP对样式注入的限制形同虚设属于妥协方案。还有一个常见的误伤来源是前端框架运行时注入样式。有些组件库会在运行时把样式写到style标签里不是你想外链就能外链的。碰到这种可以考虑给相关页面单独配一条宽松些的CSP别让全站CSP因为一个页面被拉低。4.3 HSTS开了回不去这个坑属于“配置容易、回滚难”的典型。具体现象加了HSTS头后调试环境或者测试域名因为证书过期、或临时需要用HTTP访问发现浏览器怎么都不肯走HTTP一直在HTTPS报错页面上转。原因就是前面说的“浏览器记住了HSTS策略”。解决思路有几个第一次上线用max-age60这种短时间观察确认没问题再改一年。这是最推荐的稳妥路线。测试时用无痕窗口或者临时换一个浏览器内核避开本地记忆的HSTS策略。如果确实要走HTTP调试可以在浏览器地址栏手动输入http://试试部分浏览器会在HSTS enforce下自动跳到HTTPS这个行为没法通过服务端配置临时关闭。如果访问的是子域还受includeSubDomains约束那整个域的HTTP访问基本被锁死。4.4 上游后端把安全头覆盖了代理场景下Nginx的add_header行为不会替换上游返回的同名头。比如后端Java服务在代码里设置了X-Frame-Options: ALLOWALLNginx层配的SAMEORIGIN根本不会生效。响应头以第一次出现的值为准实际是浏览器读取时通常取最先出现的或者更准确说是合并处理时看代理如何拼接。要强制统一Nginx层的安全头可以用proxy_hide_header先隐藏上游的同名头location / { proxy_hide_header Content-Security-Policy; proxy_hide_header X-Frame-Options; proxy_hide_header Strict-Transport-Security; include conf.d/security.conf; proxy_pass http://backend; }注意顺序proxy_hide_header要在add_header之前逻辑是先剥掉后端的再补自己的。这也是为什么所有add_header统一写在配置前面更不容易踩坑。4.5 安全头多但页面加载变慢多半是心理作用配置完所有安全头有人用curl -w对比响应时间发现加了几个头之后慢了几毫秒开始担心性能。实际上HTTP头增加几十字节对网络传输影响微乎其微真正的影响来自CSP对浏览器加载资源的限制导致的重试或阻塞——比如CSP白名单配错了浏览器先尝试加载再被拦截白等一次资源超时。这就不是性能问题而是配置错误导致的资源加载失败。真为性能考虑给静态资源单独配location并放行缓存给动态接口沿用全局安全头。安全头本身不是性能瓶颈别在排查方向上百忙一场。4.6 常见问题速查表把上面这些整理成一个速查表方便直接查现象原因处理404页面不含安全头add_header漏了always所有安全头加上alwayslocation接口缺安全头location里自己的add_header冲掉了server层include公共配置或在location重复add_header页面白屏并报样式拒绝CSP的style-src不允许内联样式样式外链化或单独放宽上游响应头覆盖Nginx配置后端代码设置了同名响应头proxy_hide_header先隐藏再add_headercookies不带Secure/HttpOnly应用层Cookie报文直接设置proxy_cookie_flags统一追加属性HSTS生效后无法退回HTTP浏览器已记住长max-age首次配置用短max-age加载外部资源全部被拦CSP白名单未包含第三方域名在对应指令里追加来源域名最后再分享一个小技巧我自己的习惯是每配完一批安全头就用curl把主域名和几个核心API路径全部扫一遍响应头再开浏览器过一遍主流程页面双管齐下。安全报告上的10个“漏洞”其实用不了一天就能填完真正的功夫在填完之后CSP别一次拉太紧、HSTS别一开始就一年、add_header别随手写在location里。这套配置跑稳之后后面新接入的站点直接照搬五分钟一个站。先跑起来再慢慢收紧比一次性追求完美策略靠谱得多。