我盯着一家银行的开发者文档看了三个小时，终于在一个角落找到了那个参数——user_id=12345。抱着试试看的心态，我把数字改成了12344。页面刷新，屏幕上出现了另一个人的姓名、身份证号、银行卡余额。那一刻我后背发凉，这还只是最简单的水平越权漏洞，连加密都没做。

API漏洞和传统网页漏洞不太一样。SQL注入、XSS这些老面孔还在，但API把攻击面彻底摊开了——每个端点都是门，参数就是钥匙。有些门根本没锁，有些钥匙能开所有门。更麻烦的是，API是机器对机器说话，没人盯着，攻击者可以慢慢试，一天试一万次也不会触发任何警报。

有个真实案例让我印象很深。某外卖平台搞了积分兑换功能，用户下单后调用一个API接口加积分。正常逻辑是：提交订单号，服务器验证订单属于当前用户，然后加积分。但开发偷懒，直接用了订单金额作为参数传给另一个内部接口。结果呢？有人抓包发现，把金额参数改成负数，积分不增反减，但系统只校验了订单状态，没校验金额值。那人疯狂下单又退款，积分刷了几百万，换了一堆实物礼品。平台发现时，损失已经超过六位数。

这类问题根子上是信任边界没划清。前端传什么，后端就信什么，中间没有任何签名、时间戳、一次性token之类的防护。说白了，API设计时默认“调用者都是自己人”，可公网上的API，谁都能调。

还有更隐蔽的。有个做智能硬件的公司，他们的设备通过API上报数据，服务器下发指令。安全研究员发现，设备注册时只验证了MAC地址，而MAC地址是可以伪造的。他随手改了MAC，冒充别人的设备，就能远程控制那台设备——比如打开别人家的智能门锁。这已经不只是数据泄露了，是物理世界的人身安全。

我见过不少开发者的心态：先上线，再补漏洞。可API这东西，一旦上线，第三方应用、内部系统、合作伙伴全都接进来了，想改个参数格式都得协调一堆人。修补成本比开发时多花半小时做鉴权高得多。更讽刺的是，很多漏洞不是黑客挖出来的，是合作方程序员调试时不小心发现的——他们随手把别人的ID填进去测试，结果真的能查到数据。

说到底，API漏洞的本质是“接口信任了不该信任的输入”。解决思路也不复杂：每个请求都要验证身份，每个对象都要验证权限，每个参数都要验证合法性。但现实是，业务压力一来，这些“每个”就变成了“偶尔”。我见过某大厂内部API文档里，鉴权字段标注着“可选”，因为“内部调用方便”。直到被爬虫薅走几千万条用户数据，才改成“必填”。

别指望安全工具能兜底。WAF能拦常见攻击，但拦不住逻辑漏洞——比如那个改订单金额的，流量完全正常，只是数值不对劲。真正的防线只有一条：写代码的人时刻想着“如果有人恶意调用这个接口，会发生什么”。想不明白的话，建议自己先拿Burp Suite改几个参数试试，比看十篇安全文章都管用。

(责任编辑：综合)