2019年冬天，系统漏洞我帮一个做电商的系统漏洞朋友查后台数据。他跟我说，系统漏洞最近一周订单量突然涨了30%，系统漏洞但利润没变。系统漏洞我翻了翻日志，系统漏洞发现所有异常订单都来自同一个IP段，系统漏洞收货地址全是系统漏洞虚构的，付款方式清一色是系统漏洞货到付款。更诡异的系统漏洞是，这些订单的系统漏洞收货人姓名，全是系统漏洞同一个名字的拼音变体。
这就是系统漏洞典型的系统漏洞被利用了。有人写了个脚本，系统漏洞批量下单，系统漏洞占用库存，然后等商家发货后拒收。商家承担来回运费，每单亏十几块。朋友那周发了三千多单，光运费就烧掉四万多。
漏洞在哪？他用的那套开源商城系统，订单接口没有做频率限制。正常用户下单一次要填地址、选规格、确认支付，至少花十几秒。脚本一秒钟能提交几十次。系统分不清是人还是机器。
我后来留意了一下，这类事情比想象中普遍。去年有个做在线教育的客户，他们的优惠券系统被薅了。漏洞更简单：优惠券领取接口返回的JSON里，带了一个is_used字段。用户领完券，前端把is_used改成false，再提交订单，系统就认。一个券能反复用，直到他们发现账户里多了两千多笔零元订单。
修这个漏洞花了他们三天。第一天改前端校验，第二天发现后端也没验，第三天把优惠券状态改成服务端强一致。上线那天，技术负责人跟我说了句话：“我们一直以为前端改了，后端就安全了。其实前端只是个建议。”
这话我记到现在。很多系统漏洞的根源，就是把“建议”当成了“强制”。前端校验是给正常用户看的，后端校验才是给所有人看的。但开发的时候，人容易偷懒。接口写完了，前端调通了，测试过了，就上线了。没人会主动想：如果有人绕过前端直接调接口呢？
还有一类漏洞更隐蔽——逻辑漏洞。不是代码写错了，是流程设计有缺陷。比如某次我见到一个退款系统，退款金额是前端传的。用户申请退100块，前端传amount=100，后端直接按这个数退。那如果传amount=10000呢？系统照退。因为后端信任了前端传来的数字，没跟订单实际金额比对。
这种漏洞扫描器扫不出来。它不涉及SQL注入，不涉及XSS，代码本身没毛病。毛病出在“谁说了算”这件事上。退款金额应该由服务端根据订单记录算，而不是由客户端告诉服务端该退多少。
我见过最离谱的一个案例，是某公司的员工权限系统。系统里有个“管理员”角色，普通员工看不到管理菜单。但接口没做角色校验。一个员工用普通账号登录，抓包把请求里的role=user改成role=admin，再调管理接口，直接进了后台。他后来跟我说，他当时只是想试试，没想到真进去了。
这些事听多了，我慢慢形成一个判断：系统漏洞很少是技术难题，更多是态度问题。开发的时候多问一句“如果别人不按我设想的来呢”，能挡掉一大半事故。但现实是，项目排期紧，需求催得急，人倾向于假设“用户会正常操作”。可攻击者从来就不正常。
朋友那家电商后来加了限流，也加了风控。但他说，每次大促前还是会紧张。因为漏洞这东西，修完一个，下一个可能已经在路上了。你永远不知道，下一个绕开你“建议”的人，会从哪个口子进来。