做Web服务这么多年有件事我一直觉得挺魔幻的很多团队会在服务器上花大力气配防火墙、上WAF、做各种渗透测试但HTTP安全响应头这块却常常是空白。更要命的是这种事不是小作坊才会犯你去访问很多头部大厂的页面打开浏览器的Network面板看一眼Response Headers照样能挑出一堆问题——要么整个安全响应头一个都没配要么配了CSP却漏了Permissions-Policy要么HSTS的max-age短得跟开玩笑似的。HTTP安全响应头不是一个多么复杂的东西它就是服务器在HTTP响应里带的一组元数据告诉浏览器要启用哪些安全保护机制。很多攻击之所以能得手不是因为攻击者多高明而是因为你的网站在响应头层面把防御的窗户全打开了。这篇文章我不整虚的直接把我实际测试过的安全响应头清单、各个场景的配置方式、以及我踩过的坑全部整理出来末尾会给一份可以直接复制粘贴的配置清单你拿去照着改就行。1. 为什么安全响应头总被当成可选优化项1.1 安全响应头是什么能挡住哪些攻击先花两分钟把基础对齐。HTTP安全响应头不是某个框架的特性也不是某个中间件的插件它是HTTP协议本身的机制。服务器在返回响应时往Response Headers里塞几个字段浏览器读到这些字段后就会执行对应的安全策略。这些策略组合在一起相当于给浏览器装上了一圈主动防御的护甲。举个最直观的例子X-Frame-Options这个头。如果没有它你的页面就能被别的网站用iframe嵌进去。攻击者做一个和你的登录页一模一样的透明iframe叠在自己的恶意页面上诱导用户输入账号密码这就是典型的点击劫持。很多金融类网站的登录页至今还能被iframe嵌入本质上就是X-Frame-Options没配或者配错了。再比如CSPContent-Security-Policy它的作用类似给浏览器开了一份白名单明确告诉浏览器脚本、样式、图片只能从哪些来源加载。如果攻击者往你的页面里注入了一段恶意脚本而你的CSP又没有放开不可信来源浏览器会直接拒绝执行这段脚本。这是目前防XSS最有效的一层防线比后端各种过滤函数靠谱得多。1.2 大厂漏配的三个真实原因为什么大厂也会漏配我分析下来原因不外乎三个。第一个是研发流程里根本没有这一环。大多数团队的开发流程是写功能、联调、测试、上线。安全响应头不直接影响功能漏了不会报错也不会让用户打开页面出现异常所以只要没有专门的安全团队卡上线流程它就是那个永远没人管的角落。第二个是框架默认配置不全。Spring Boot、Express、Django这些框架确实内置了一些默认安全头但覆盖范围有限。比如框架不会帮你配CSP因为要满足所有业务场景的CSP太困难了框架不敢替你决定Permissions-Policy同理。结果就是开发者以为框架帮忙兜底了实际上兜了个寂寞。第三个是多层架构下的信息断层。现代Web服务很少是单台服务器直接面对用户前面通常还有Nginx、网关、CDN响应头可以在任意一层加。负责网关的团队觉得头应该在应用层配应用团队觉得网关层已经把安全做了吧两边一互相甩锅头就没了。更隐蔽的情况是CDN缓存源站改了响应头但CDN节点没回源或者缓存的旧响应还在有效期内用户拿到的还是旧头。2. 我实测过的安全响应头清单三层分级配置思路2.1 第一梯队不配等于裸奔第一个必须配的是HSTS全称Strict-Transport-Security。它的作用是告诉浏览器以后访问我的域名只准用HTTPS不要用HTTP一次都不行。这个头防的主要是协议降级攻击和数据被明文劫持。比如用户在一个公共Wi-Fi下访问你的网站如果没有HSTS攻击者可以通过DNS劫持或中间人手段把HTTPS请求偷偷降级成HTTP用户在地址栏看到的可能还是那个网站但传输的数据已经全是明文了。配置HSTS之后只要浏览器访问过一次你的HTTPS页面就会记住这个策略后面哪怕用户手动在地址栏输入http://浏览器也会自动跳转成HTTPS。第二个是CSP。前面提到过我再补充一个细节CSP的粒度可以非常细细到这个页面只允许从你自己的域名加载脚本脚本的src属性不允许使用data:协议不允许使用eval()。配置得当的情况下反射型XSS和存储型XSS的有效性会大幅降低。常见的配置指令有default-src、script-src、style-src、img-src、connect-src、frame-ancestors每个指令都可以单独声明允许的来源。第三个是X-Frame-Options。它的配置非常简单安全取值就两个DENY表示任何网站都不能嵌入你的页面SAMEORIGIN表示只有同源页面能嵌入。如果你不确定业务上有没有被第三方合法嵌入的需求就先用SAMEORIGIN。这个头现在和CSP的frame-ancestors指令存在功能重叠但它在老浏览器上的兼容性更好所以依然值得保留。2.2 第二梯队几行配置消除低级漏洞第二梯队这几个响应头单个看起来都很小但组合在一起能消灭一大片低级漏洞。X-Content-Type-Options专门对付MIME类型嗅探。正常情况下服务器通过Content-Type告诉浏览器响应是什么类型。但老版本浏览器有个毛病会去嗅探响应内容来猜测类型比如你明明返回的是text/plain浏览器看内容长得像HTML就自作主张当成HTML执行了。攻击者可以利用这点绕过上传限制上传一个内容像HTML但Content-Type是其它类型的文件诱导浏览器执行。配置X-Content-Type-Options: nosniff之后浏览器会严格信任服务器返回的Content-Type不做任何猜测。Referrer-Policy控制的是浏览器在页面跳转时把当前页面的URL信息带到目标网站这个行为。默认的no-referrer-when-downgrade在大多数情况下够用但我更推荐strict-origin-when-cross-origin同源请求带完整URL跨源请求只带origin且HTTPS页面跳HTTP时不带任何Referrer。这样既保证了业务上需要的Referrer信息又避免把URL里的敏感参数比如token、sessionId泄露给第三方网站。Permissions-Policy这个头在不少团队的配置清单里是缺席的。它的作用是限制浏览器功能比如你的网站根本不用麦克风那就直接声明microphone()这样页面上任何脚本都无法调用麦克风API。类似的功能还有geolocation定位、camera摄像头、usbUSB设备等。你不声明的功能默认也有可能被某些脚本调用显式声明禁用是一种防御性的做法。2.3 第三梯队跨源隔离很多人听都没听过第三梯队这三个响应头属于进阶玩法核心是围绕跨源隔离Cross-Origin Isolation做的很多团队的运维和前端甚至没听过。Cross-Origin-Opener-PolicyCOOP控制的是当前页面通过window.open或target_blank打开的新页面以及它们之间的反向关联。如果没有COOP一个恶意站点可以通过引用你的页面拿到window.opener然后修改location、读取敏感信息。配置COOP: same-origin之后跨源的opener关系会被彻底切断。Cross-Origin-Resource-PolicyCORP控制的是别的站点能不能加载你站点的资源。如果你这个站点是纯API或者纯资源站不打算给任何第三方用可以配置CORP: same-site或same-origin。这样即便有人在自己的页面里通过