上周三下午，低危运维群里弹出一条告警：某后台管理系统登录接口的漏洞响应头里，缺少了 X-Content-Type-Options 和 X-Frame-Options。整改扫描器标的情况是“低危”，CVSS 评分 3.1。报告值班同事看了一眼，低危顺手把工单丢进了“下周处理”的漏洞队列。

这种事太常见了。整改低危漏洞在很多人眼里约等于“不用管”——不影响业务，情况不泄露数据，报告不拿权限。低危但这次不一样。漏洞那个登录接口背后挂着一个老旧的整改运营后台，页面里嵌了第三方统计脚本，情况而统计脚本的报告域名半年前就过期了。缺少 X-Frame-Options 意味着这个后台可以被任意网站用 iframe 嵌套。攻击者只需要做一个假抽奖页面，把后台登录框透明覆盖在“点击领奖”按钮上，就能诱导已经登录的运营人员完成一次点击劫持操作。

我们决定不按常规流程走。没有开整改会，没有写方案文档。我直接拉上负责那个系统的后端老张，在工位上花了二十分钟改了三行 Nginx 配置：

add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff"; add_header Content-Security-Policy "frame-ancestors 'self'"; 

改完 reload，用 curl 验证响应头，再让安全同事用扫描器复测。从发现到闭环，总共不到四十分钟。老张说了一句：“早该这么干，之前总觉得低危不急，结果一拖就是三个月。”

这件事让我重新翻了一遍近半年的漏洞台账。低危漏洞的平均修复周期是 47 天，而高危是 6 天。差距不在技术难度，在心理优先级。低危漏洞往往对应的是配置缺失、信息泄露、版本号暴露这类“看起来不痛不痒”的问题。但攻击链从来不是单点突破。一个低危的目录遍历可能暴露备份文件，备份文件里可能有数据库连接串，连接串可能指向一个未授权访问的 Redis。低危是拼图的一块，不是可以扔掉的那块。

具体到整改动作，我做了三件事。第一，把扫描器里所有“低危”按类型重新归类。配置类漏洞（缺失安全头、Cookie 未设 HttpOnly、错误页面泄露版本）占了 68%，这类问题批量修复成本极低，一个 Nginx 全局配置或者一个中间件拦截器就能覆盖八成。第二，信息泄露类漏洞单独拉出来，比如 .git 目录暴露、phpinfo 页面残留、API 返回堆栈信息。这类问题不能只靠扫描器，得让开发在代码里加异常兜底和响应过滤。第三，剩下的低危漏洞里，凡是涉及第三方组件版本过低的，一律升级。Log4j 那种事没人想再来一次，而低危列表里躺着的旧版 Fastjson、旧版 Shiro，就是定时炸弹。

执行过程中有个细节值得说。批量加安全头之后，有两个内部管理系统页面样式错乱了。排查发现是 Content-Security-Policy 把内联样式和 eval 给拦了。这其实是个好事——说明这些系统还在用十年前的前端写法。我们没有回退 CSP，而是让前端把内联样式挪到外部文件，把 eval 改成 JSON.parse。低危漏洞整改顺带清理了技术债，这种附带收益比漏洞本身更有价值。

现在回头看，低危漏洞整改的核心不是“修不修”，而是“怎么批量修、怎么防止再出现”。靠人盯工单没用，得靠流水线。我们在 CI 里加了一个检查步骤：任何新部署的服务，如果响应头缺少那三项，直接构建失败。第一次跑的时候拦下了四个服务，开发骂骂咧咧地改了。第二次跑，零失败。规则一旦变成自动化的，低危就不再是“下周处理”的选项了。

那个点击劫持的风险最后没有真实发生过。但我知道它离发生只差一个过期域名和一次粗心点击。低危漏洞像房间角落的灰尘，不扫不会塌房子，但扫了才知道角落到底堆了多少东西。