上个月，口渗一家金融科技公司找我做外部测试。透测他们的口渗API文档写得漂亮，OAuth2.0、透测JWT、口渗Rate Limiting一应俱全。透测我花了二十分钟翻文档，口渗发现一个细节——密码重置接口返回的透测验证码有效期是600秒。十分钟，口渗足够我写个脚本暴力枚举四位数字了。透测结果你猜怎么着？口渗第三十七次尝试就进去了。不是透测他们技术差，是口渗开发觉得“验证码六位数字，十分钟有效期，透测谁会盯着这个接口打？口渗”

API渗透和传统Web渗透完全是两回事。传统渗透像撬门锁，你面对的是一个静态目标。API渗透更像在迷宫里追一个会跑的兔子——每个端点都是独立的门，每个参数都可能藏着后门。而且API的逻辑漏洞远比技术漏洞多。SQL注入、XSS这些老套路在API里反而少见，因为开发者普遍有安全意识了。真正致命的是业务逻辑：越权访问、批量数据抓取、验证码绕过、价格篡改。

我见过最经典的案例是某电商平台的订单查询接口。他们用UUID作为订单号，觉得随机性够强。但UUID v4的随机源是伪随机的，如果种子可预测，整个订单系统就是透明的。更蠢的是，他们还在另一个接口里泄露了生成UUID的种子值。这就像把保险箱密码写在便利贴上，然后贴在保险箱旁边。

测试API有个铁律：先摸清资产边界。很多人上来就扫目录、跑字典，纯属浪费时间。你得先读文档，读不懂就抓包，抓不到包就看JS文件里的硬编码。有一次我盯上一个物联网平台，他们的APP里嵌了个调试模式，开启后能看到所有内部API的调用日志。这不算漏洞，但给了我完整的API地图。有了地图，接下来的事就顺理成章了——我找到个上传固件的接口，没校验文件类型，直接传了个反弹Shell的脚本。整个过程没触发任何告警，因为他们的WAF只检查了HTTP头，没看multipart/form-data的body内容。

参数篡改是另一个高发区。开发人员总爱在客户端做判断，服务端只信前端传来的值。比如一个修改用户资料的接口，把role参数从user改成admin，很多系统就直接放行。更隐蔽的是数组注入——如果接口接受id[]=1&id[]=2这种格式，你传个id[0]=1&id[1]=2，某些框架会解析成嵌套数组，导致SQL拼接出错，反而泄露了表结构。

别忽视HTTP方法。RESTful设计里，GET应该只读，POST才写数据。但总有开发图省事，把删除操作也放在GET里。我见过一个客户管理系统，删除用户的接口是GET /api/user/delete?id=1。你猜怎么着？他们的爬虫程序无意中遍历了所有用户ID，把整个客户库清空了。事后他们说是“爬虫误触”，其实是API设计得蠢。

速率限制是个摆设。很多API声称有Rate Limiting，但实现方式是按IP限流。用分布式代理池就能轻易绕过。更可笑的是，有些限流只限制登录接口，对业务接口完全放开。批量查询用户信息的接口，一分钟请求几千次都没问题。这种数据泄露不是技术漏洞，是业务设计缺陷。

最后说点实在的。测试API别光盯着漏洞，要看数据流向。从用户输入到数据库查询，中间每跳一层都可能被篡改。我习惯用Burp的Logger++记录所有请求，然后用脚本分析参数名和值的规律。如果发现userId和user_id同时存在，那八成是前后端字段映射不一致，这种地方最容易出越权。

API渗透的本质是猜心思——猜开发者哪里偷懒了，哪里过度信任了，哪里以为没人会注意到。他们总在文档里写“本接口仅供内部使用”，但互联网上没有内部。每个暴露的端口都是攻击面，每个参数都是机会。别迷信扫描器，手工测试永远比工具靠谱。工具只能发现已知问题，而你能发现开发者自己都没意识到的愚蠢。