去年有个做电商的隐藏意思朋友找我，说他的漏洞优惠券系统被人薅了十几万。我问他代码审查过没有，和明他说审查了三遍，显漏逻辑没问题。隐藏意思后来我看了他的漏洞代码，确实，和明从业务逻辑上讲，显漏每张优惠券只能领一次，隐藏意思判断条件写得很清楚。漏洞但问题出在他用的和明那个开源框架上——框架底层有个并发处理的bug，在高并发场景下会导致重复插入。显漏这个bug不在他的隐藏意思代码里，在依赖库里，漏洞社区里早就有人提了issue，和明但他不知道。

这就是典型的隐藏漏洞。你看不见它，不是因为你粗心，而是因为它压根不在你关注的范围内。

隐藏漏洞和明显漏洞的区别，说白了就一句话：明显漏洞是你知道该看哪里但没看好，隐藏漏洞是你根本不知道要看那里。

明显漏洞长什么样？举个例子。登录接口没做频率限制，攻击者可以无限次撞库。这种漏洞，你随便找个安全扫描工具都能报出来。再比如，用户输入直接拼接到SQL语句里，导致注入。这类问题有大量的最佳实践、检查清单、自动化工具去覆盖。它的特点是：已知的、有共识的、能被标准化检测的。

隐藏漏洞完全是另一回事。它往往藏在三个地方。

第一个地方：依赖链的深处。你用npm装了一个包，这个包依赖了另外五个包，那五个包又各自依赖了十几个包。其中某个包的某个版本有个内存泄漏，平时没事，流量一上来就崩。你不知道，因为你只看了自己写的代码。2021年的Log4j漏洞就是这种——全球几百万个Java应用都在用，但大部分开发者根本不知道自己间接依赖了它。

第二个地方：业务逻辑的组合缝隙。单个功能看起来都对，但两个功能串起来就出问题。比如一个系统允许用户修改邮箱，修改后需要验证新邮箱。另一个功能允许用户用旧邮箱找回密码。单独看，每个流程都合理。但组合起来：攻击者先绑定自己的邮箱，触发验证邮件但不点击，然后立刻改回原邮箱。系统此时的状态是“新邮箱待验证”，但密码找回逻辑读的是“当前邮箱”字段。这就产生了一个时间窗口，攻击者可以用未验证的邮箱接管账户。这种漏洞没有工具能扫出来，它需要对业务全流程的理解。

第三个地方：人的认知盲区。开发团队默认“用户不会这么做”，但攻击者偏偏就这么做。比如参数传负数、传超大数组、传特殊字符、在JSON里嵌套一百层。你觉得不可能发生的输入，在攻击者手里就是武器。

我说句可能不太中听的话：大部分团队把精力花在修明显漏洞上，因为修起来有成就感，扫描报告上的数字在减少。但真正造成重大损失的，往往是隐藏漏洞。明显漏洞像你家门没锁，路过的人都能看见。隐藏漏洞像你家墙里有一根电线老化了，住了三年都没事，直到某个夏天开空调同时用微波炉，烧了。

怎么对付隐藏漏洞？没有银弹。但有几个做法确实有用。一是把依赖库的版本锁定，定期用工具检查已知漏洞，别等出事再查。二是做威胁建模的时候，别只盯着单个接口，把完整业务链路画出来，看数据在各个环节之间怎么流转。三是搞安全的人别只跟代码打交道，多跟产品和运营聊，他们知道用户实际会怎么用系统，那些“不按套路出牌”的用法，往往就是隐藏漏洞的入口。

说到底，明显漏洞考的是执行力，隐藏漏洞考的是认知深度。执行力可以靠流程和工具堆出来，认知深度只能靠时间和踩坑积累。这大概也是为什么安全这行，经验永远比工具值钱。