🛡️ API 安全怎么做——六类风险与分层防护方案

1 API 安全为什么成了新的主战场

过去十年，企业把防护重心放在 Web 页面和网络边界上，WAF、防火墙、IPS 层层堆叠。但业务架构变了：前端页面调后端接口，App 调 API，合作伙伴调开放接口，内部系统之间也走 API。数据真正的出入口，从页面转移到了接口。

这带来一个尴尬局面：传统 WAF 看的是 HTTP 请求里的攻击特征，对 API 的业务逻辑滥用几乎无感。攻击者不需要注入恶意代码，只要按正常格式反复调用接口，就能把数据一点点搬走。这类攻击在日志里看起来全是合法请求。

API 安全的难点在于它不只是技术问题。一个企业往往有几百上千个接口，很多是历史遗留、文档缺失、没人维护的。不知道有哪些接口，就谈不上保护。所以 API 安全的第一步永远是资产梳理，而不是买设备。

2 六类高频 API 风险

OWASP API Security Top 10 给出了权威分类，落到国内企业的实际情况，最容易出问题的集中在下面几类。

这六类里，越权访问造成的实际损失最大。它不需要任何技术技巧，改个参数就行。很多企业做了加密、做了 WAF，却在这个最朴素的问题上翻车。

3 第一步：把接口摸清楚

没梳理过接口的企业，第一次做资产盘点通常会发现实际接口数量是预期的三到五倍。梳理方法有几种，可以组合使用。

从网关日志反推。如果有统一网关，日志里记录了所有经过的请求路径，按路径去重就是接口清单。这是最靠谱的方式，因为记录的是真实流量，不依赖文档。

从代码扫描提取。扫描代码里的路由定义，能拿到接口清单，但会包含未上线的、已废弃的。适合开发阶段用，运行阶段以日志为准。

从流量镜像识别。在出口做流量镜像，被动识别所有 API 调用。这种方式对遗留系统和第三方对接特别有效，因为不依赖任何配合。

清单出来后，给每个接口打三个标签：是否对外、是否涉及敏感数据、是否有鉴权。三个标签一交叉，优先级就出来了。对外加敏感数据加无鉴权的，先处理。

4 第二步：分层建设防护能力

API 防护不是单一产品能解决的，需要从开发侧、网关侧、监测侧三层同时下手。

5 选型看哪几个能力

市面上的 API 安全产品分两类：一类是传统 WAF 厂商扩展出的 API 防护模块，一类是专门的 API 安全平台。选型时重点看下面几点。

能不能自动发现接口。靠人工录入清单的产品，实际用起来会迅速失效，因为接口一直在变。要看它是否支持流量学习自动生成接口画像。

能不能识别业务逻辑滥用。这是 API 安全和传统 WAF 的核心区别。要看它有没有针对越权、批量拉取、参数遍历的检测规则，而不只是 SQL 注入、XSS 这些老一套。

误报率能不能接受。API 流量里正常业务和异常行为界限模糊，规则太严会阻断正常调用。要求厂商提供试用，用自己的真实流量跑一周看误报情况。

和现有架构怎么集成。是旁路镜像还是串行代理，对性能影响多大，能不能和现有网关共存。串行方案防护更彻底但有单点风险，旁路方案无侵入但只能告警不能阻断。

6 落地节奏：三个月能做到什么程度

第一个月，做资产和风险基线。梳理接口清单，打标签定优先级。同时对高优先级接口做一轮人工渗透，把明显的越权和未授权访问先修掉。这个阶段不需要买产品，靠人力和流程就能拿到大部分收益。

第二个月，上统一网关和基础防护。把散落的接口收敛到统一网关，开启认证、限流、参数校验。同步部署 API 监测，先跑观察模式不做阻断，积累流量基线。

第三个月，调优和常态化。根据观察期的数据调整规则，把误报压到可接受范围，再逐步开启阻断。建立接口变更流程，新接口上线前必须过安全检查。

这个节奏的前提是有专人推进。API 安全涉及开发、运维、安全三方，没有牵头人很容易卡在协调上。

7 云上可用的 API 防护能力

云上产品的好处是和网关、负载均衡、日志服务天然打通，接入成本低。选之前建议先申请试用，用自己的真实接口流量跑一段时间，重点看误报和对业务的影响。