上周三下午，低危安全组丢过来一份扫描报告，漏洞标了17个低危漏洞。整改我扫了一眼，报告全是低危些“缺少HTTP安全头”“Cookie未设置Secure属性”之类的东西。按流程，漏洞这种级别的整改漏洞给两周整改期就行，不急。报告但真正动手改的低危时候，我发现事情没那么简单。漏洞

先说最典型的整改一个：X-Frame-Options响应头缺失。扫描器说这可能导致点击劫持。报告听起来挺吓人，低危实际上要利用这个漏洞，漏洞攻击者得先让用户访问一个恶意页面，整改页面里嵌我们的站点，再诱导用户点击。前提条件不少，危害也确实有限。但既然报了，就顺手加上吧。结果改完nginx配置，测试环境正常，预发布环境也正常，上线之后客服那边来了反馈——有个客户用iframe嵌我们的报表页面做内部看板，现在全白了。一个低危漏洞的修复，把人家正常业务搞挂了。

这事让我重新想了一个问题：低危漏洞到底该怎么整？

安全扫描器是按规则匹配的，它不管你业务怎么跑。X-Frame-Options设成DENY最安全，但如果有合法的嵌入需求，就得用ALLOW-FROM或者CSP的frame-ancestors来精细化控制。我们后来改成只允许特定域名嵌入，花了额外半天时间跟客户确认他们的域名列表。扫描器不会告诉你这些。

Cookie的Secure属性也是类似的情况。扫描报告说会话Cookie没有标记Secure，意味着可能通过HTTP明文传输。但我们的站点全站HTTPS，HSTS也开了，实际上Cookie不太可能走HTTP。不过既然要改，就在Set-Cookie里加上Secure和HttpOnly。改完发现有个老旧的内部工具通过HTTP调接口，Cookie带不上了，登录态直接丢失。那个工具是运维自己写的小脚本，平时没人管，但确实在用。

还有一类低危漏洞纯粹是信息泄露。比如服务器版本号暴露在响应头里，扫描器建议隐藏。这个改起来最简单，nginx里加一行server_tokens off就完事。但说实话，隐藏版本号对真正想攻击的人来说意义不大，人家有的是办法探测。它的价值在于不让自动化扫描器一眼就认出你用的是哪个版本的nginx，降低被批量扫描命中的概率。算是一种“不招贼”的策略。

17个漏洞里，真正改代码的只有3个，其余都是配置层面的调整。但每一个改动我都让测试跑了回归。低危不代表零风险，也不代表改了就没风险。恰恰相反，低危漏洞的修复往往涉及面更广——它们大多是全局配置，一动就是全站生效。

有个搞安全的朋友跟我说过一句话：低危漏洞像房间里的小裂缝，不补不会塌，但补的时候可能把墙敲坏。这话糙，但挺准。我的做法是，每次改低危漏洞之前先问三个问题：这个配置谁在用？改了之后谁会受影响？有没有更小粒度的方案？想清楚再动手，比闷头改完再救火强得多。

最后那17个漏洞花了四天全部关闭。多出来的时间基本都花在沟通和验证上，真正敲键盘改配置的时间加起来不到两小时。这大概就是低危漏洞整改的真相——技术难度不高，但需要你对系统足够熟，对影响面足够敏感。扫描器给你的是清单，怎么改、改到什么程度，还是得自己判断。