先承认一件事：多数组织不知道自己有多少 API
业务系统越来越多地通过接口对外提供服务，API 也随之成为数据泄露的主要通道之一。但绝大多数组织在真正梳理之前，都无法准确回答一个最基本的问题：我们有多少个 API，分别由谁维护，暴露在哪里。
这带来一个典型的困境：安全团队在为已知的几十个接口做防护，而实际存在的可能是几千个——包括历史遗留的旧版本、测试环境暴露的调试接口、以及前端为了图方便直接开放的内部接口。这些“影子接口”通常没有文档、没有负责人，也没有纳入任何防护策略。 因此 API 安全治理的第一个层次永远是资产发现，而不是防护规则。
三个层次
层次一：资产发现。 主要手段有三类：从网关与负载均衡日志提取实际被访问的接口清单；从全流量分析识别未经过网关的直连接口；从代码与接口文档提取设计态清单。三者交叉比对，差异部分最需要关注——特别是“在流量里存在、在文档里没有”的接口。发现之后要给每个接口打上标签：所属业务、数据敏感度、是否对外、负责人。
层次二：鉴权与授权。 这是 API 风险最集中的地方，也是最容易被误解的地方。多数团队会确认“接口需要认证”，但真正出问题的是授权——用户 A 能不能访问用户 B 的数据。
两类最常见的缺陷是：对象级授权缺失（接口只校验了“已登录”，没有校验“这个对象属不属于你”，改一下请求里的对象标识就能读到别人的数据），以及功能级授权缺失（普通用户可以通过直接调用管理接口完成越权操作）。此外还有过度数据暴露——接口返回了整个数据对象，而前端只需要其中两个字段，多余的敏感字段就这样泄露了。
对应的工程要求很明确：授权校验必须在服务端完成、必须针对每一个对象校验归属、返回字段必须按需裁剪。仅靠前端隐藏字段或依赖客户端校验，等同于没有控制。
层次三：运行时防护。 这一层解决“上线后来不及改”的问题，主要动作包括：Schema 校验（请求与响应是否符合约定的结构与类型，异常即拦截）、速率限制与配额（按接口、账号、来源维度限制，防范资源耗尽与批量爬取）、以及行为基线（识别大量枚举对象标识、异常时段调用等模式）。它的价值在于争取时间——不能替代授权修复，但能在漏洞修复上线前降低被利用的概率。
几个高频问题
- 只依赖网关：绕过网关的直连接口完全没有管控；
- 旧版本接口未下线：新版本加了鉴权，v1 版本仍在运行；
- 授权逻辑写在前端或仅校验登录状态；
- 接口返回全量对象，包含不必要的敏感字段，且没有速率限制；
- 调试接口未清理：测试环境与生产环境网络互通，成为后门。
落地建议
建议按这个顺序：先做发现与台账（不知道有什么就无法保护），再收敛暴露面（下线旧版本与调试接口、直连改为经网关），然后修复授权（对象级校验与字段裁剪），最后上运行时防护。
一句话总结：API 安全的起点是“列出全部接口并找到负责人”，终点是“每一个对象访问都在服务端被校验过归属”。中间任何一环跳过，都会留下可被批量利用的缺口。