一天四万次查询 ——被忽略的那条数据出口：API 接口

一、一天，四万条

先讲个真事。

一家做汽车零部件配货的平台，某天发现：有个用户账号，一天之内查询了四万多条配件价格记录。

正常业务里，一个人一天撑死查几百条。

顺藤摸瓜查下去——是个做数据生意的中介，注册了个普通账号，写了个脚本，直接调他们小程序的查询接口，把价格库整库往外爬。

更麻烦的是后来：这批数据出现在了竞品的报价系统里。

客户还以为，是平台自己把价格卖了。

二、你防住了U盘，漏掉了接口

很多企业防泄密的思路，还停在"防内部人拷文件"。

但系统对系统的那条通道——API 接口——往往没人管。

App、小程序、开放平台、给供应商开的对接接口……每一个，都是一个数据出口。

文件泄密，有审计、有水印。

接口泄密，常常连记录都没有。

三、三个姿势：接口是怎么泄的

姿势一：不设防的接口

开发赶工期，某个查询接口忘了加登录校验；或者只在前端把入口藏了，后端裸奔。

扫端口、爬目录的工具一跑就能撞出来。撞到，就是整库拉走。

前几年不少企业"莫名泄露"客户信息，最后查出来，就是一个不带鉴权的接口被批量调用。

姿势二：改个ID，就换了个人

接口做了登录校验，但没校验"这条数据是不是你的"。

把请求里的 ID 从 10001 改成 10002，就能看别人的订单、地址、身份证号。

写个循环改 ID，等于把全库用户逛了一遍。

这类漏洞在合规通报里是常客——整改通知和罚单，都开过。

姿势三：合法身份，非法用法

像开头那个案例：接口本身没漏洞，是有人拿正常身份写了爬虫。

没有频率限制，没有调用行为分析，一天四万次调用，系统还觉得"挺正常"。

四、管住接口，四件事就够了

① 先列清单

对外的、对内的，全列出来。接口资产都不清楚，谈什么防护。

② 鉴权全覆盖

任何接口默认拒绝匿名访问；数据归属校验做到后端——别信前端。

③ 限频 + 异常识别

单账号的调用次数、时段、数据量，全部设阈值，超了就限流告警。爬虫的调用特征，其实非常明显。

④ 返回数据做收敛

列表接口能不返回手机号就不返回，能脱敏就脱敏。

先把"值得偷"的东西减下去。

五、就算被合法调走，也该知道是谁带走的

接口这层做完，还有个兜底问题：数据就算被合法调用出去了，怎么知道是谁带走的？

这里要和终端侧管控衔接起来。上邦的文档加密与外发审计体系，覆盖的正是数据落到终端之后的环节——导出的报表带水印、批量外发有留痕。

接口层管住"怎么出去"，终端层管住"出去之后"。

两层合起来，数据出口才算真正闭环。只堵一头，另一头迟早出事。

六、文件没人拷，不代表数据没走

它可能正从你看不见的接口里，一条一条地流出去。