去年冬天，业务漏洞一家做跨境电商的业务漏洞朋友找我喝酒。三杯下肚，业务漏洞他开始骂人。业务漏洞不是业务漏洞骂对手，是业务漏洞骂自己公司的技术负责人。他们搞了个促销活动，业务漏洞满200减30，业务漏洞结果运营在后台配错了参数——把"满200减30"写成了"满200减300"。业务漏洞凌晨两点上线，业务漏洞五点被羊毛党刷了四千多单。业务漏洞天亮发现时，业务漏洞损失已经六位数。业务漏洞

他拍着桌子说："这他妈也算漏洞？业务漏洞"

算。而且是业务漏洞最要命的那种。

我们总把"业务漏洞"想象成黑客电影里那种——敲几行代码，防火墙就破了，数据库随便拖。现实里哪有那么高级。绝大多数让公司赔钱的漏洞，压根不需要什么技术含量。一个输入框没做校验，一个权限判断写反了，一个金额字段忘了限制负数。就这么简单。

前年有个做知识付费的平台，用户充值页面有个"自定义金额"选项。正常人都填50、100，但有人填了-1。系统没拦，直接给账户加了1块钱余额。这人试了几次，发现负数是反向扣款，于是填了-99999。一夜之间，他账户里多了十万。平台第二天才发现，因为财务对账时发现流水总额对不上。

技术团队复盘时吵成一团。后端说前端没限制，前端说后端没校验，产品说需求文档里没写。最后谁也没背锅，因为公司三个月后就黄了。

这类事我见过太多。业务漏洞有个特点：它不挑公司大小，也不挑技术栈新旧。大厂照样出，小团队更频繁。区别只在于，大厂有专门的应急团队和公关预算，小团队只能老板亲自打电话求用户退款。

根本原因在哪儿？我觉得是"业务逻辑"和"技术实现"之间的那道缝。产品经理写需求时默认用户会按规矩来，开发写代码时默认上游数据是干净的，测试测功能时默认自己覆盖了所有边界。每个人都觉得自己那部分没问题，但拼在一起，缝就出来了。

更麻烦的是，业务漏洞往往藏在最不起眼的地方。不是登录页，不是支付接口，而是某个后台管理页面的导出按钮，或者某个只有内部员工才会用的审批流程。外部渗透测试扫不到，代码审计也容易漏——因为它看起来"没问题"，逻辑上完全说得通，只是没考虑有人会故意往反方向走。

我认识一个安全负责人，他带团队做业务漏洞挖掘时，不用扫描器，就干一件事：把每个功能当成"如果我是坏人，我怎么用它赚钱"。有次他们发现优惠券可以叠加使用，规则写的是"每单限用一张"，但代码里判断的是"每张券限用一单"。一字之差，有人领了二十张券下一单，直接免单。

他说这活儿干久了，看什么都像漏洞。去超市看到"买一送一"都下意识想：如果我把赠品退了呢？

这种思维方式很难自动化。工具能查SQL注入，能扫XSS，但查不了"这个业务规则在极端情况下会不会崩"。它需要人蹲下来，把业务从头到尾走一遍，然后在每个分叉口问一句：如果用户不按常理出牌呢？

回到开头那个朋友。他后来招了个安全工程师，专门干这个。工资不低，但比赔的钱少多了。他说现在每次上线前，都让这人先"薅一遍"。薅不动了，才敢放出去。

这大概就是业务漏洞的真相：它不酷，不高级，甚至有点蠢。但如果你不主动去找它，它就会主动来找你。而且通常是在凌晨两点，你睡得最香的时候。