恶意 API 流量并不总是表现为大规模拒绝服务攻击。它可能只是一些看似普通的请求：爬取数据、猜测验证码、创建虚假账号，或者反复触发开销较大的报表任务。即使每个请求本身都是合法的，累积起来也可能耗尽 CPU、数据库连接、带宽，或者产生高额的第三方服务费用。

防护的目标是区分正常访问和恶意请求，并限制资源消耗。OWASP 将不受限制的资源消耗归类为 API4:2023。

1. 从多个维度实施限流

仅依靠 IP 地址无法准确识别请求来源。攻击者可以通过代理网络分散请求，而多个正常用户也可能共用同一个公网 IP。

可以使用多个维度进行计数：

• IP 地址： 对匿名流量实施基础限制。

• 账号或用户 ID： 限制用户完成身份认证后的操作频率。

• API Key 或客户端 ID： 对合作伙伴应用实施配额控制。

• Session 或设备信号： 辅助识别重复行为，但不能作为稳定的身份标识。

• 接口和业务操作： 对敏感操作实施更严格的限制。

商品列表接口可以允许较高的请求频率，而密码重置、短信验证码、登录、支付和报表导出等接口则需要更严格的限制。

应根据不同操作的资源开销设置阈值，并在 API 网关层和应用层实施控制。

2. 选择合适的限流算法

固定窗口算法比较简单：允许每分钟发送指定数量的请求，然后重置计数器。但客户端可能在窗口重置前后连续发送大量请求，形成突发流量。

滑动窗口算法统计一个持续滚动时间段内的请求数量，可以缓解固定窗口重置时的突发流量问题。它有两种常见实现方式：精确记录每个请求的时间，或者使用分桶计数进行近似统计。精确计数更加准确，但资源开销也更大；分桶计数则以一定的精度损失换取更高的效率。

令牌桶算法允许短时间内出现流量突发，同时控制平均请求速率。令牌按照一定速率持续补充，每个请求都会消耗相应数量的令牌。

漏桶算法可以平滑流量，保护下游服务。它有两种常见模式：

• 整形模式（Shaping）： 请求进入队列，按照受控速率依次处理，但会增加请求延迟。

• 计量模式（Policing）： 立即判断请求是否允许通过，不进行排队，超出限制的请求直接拒绝。

应根据接口是否允许突发流量、是否需要平滑流量，以及是否要求立即限制请求来选择算法。

在分布式部署环境中，需要协调不同应用实例之间的计数器，通常可以通过 Redis 或 API 网关实现。同时，还需要考虑计数器更新的原子性，以及计数存储服务发生故障时的处理方式。

3. 限制单次请求的资源消耗

限流控制的是请求频率，并不能限制单个请求本身的资源开销。

应对分页大小、日期范围、上传文件大小、数组长度、批量操作数量，以及 GraphQL 查询深度和复杂度设置上限。

同时，还应设置执行超时时间、数据库语句执行限制、并发数量上限，并对下游服务调用增加必要的保护措施。避免允许无限制的数据查询或批量操作。

对于短信、邮件、地图、支付和 AI API 等收费服务，应设置单个用户的调用配额，以及组织级别的总费用限制。

4. 识别并处理自动化恶意流量

可以使用 Web Application Firewall（WAF）、CDN、API Gateway 或 Bot Management 服务，在可疑流量进入应用之前进行过滤。

常见的识别信号包括 IP 信誉、请求频率、异常的 User-Agent 模式，以及反复出现的请求失败。

并非所有自动化请求都是恶意流量。搜索引擎爬虫、运行状态监控、移动应用和合作伙伴集成，都可能产生正常的自动化请求。因此，需要为可信客户端设置相应的访问策略。

建议采用阶梯式处理措施：降低请求处理速度、临时限制 API Key，或者要求进行额外验证。

CAPTCHA 主要适用于面向浏览器的交互场景，例如登录和注册页面。对于无法完成交互式验证的机器对机器 API 调用或移动端 SDK，CAPTCHA 通常不应作为主要防护手段。这类 API 客户端应主要依靠身份配额、请求限流和行为分析进行保护。

5. 返回明确的错误信息并持续监控

当客户端超过限流阈值时，应返回 HTTP 429 Too Many Requests。在适用的情况下，可以通过 Retry-After 响应头告知客户端何时可以重试。

限流元数据也有助于客户端调整请求行为，但不同实现之间存在差异。目前，IETF 草案定义了 RateLimit 和 RateLimit-Policy 字段。许多服务仍然使用 X-RateLimit-Limit 和 X-RateLimit-Remaining 等实现自定义的字段。

因此，应明确说明 API 实际支持的响应头及其语义，不要假设这些字段可以互换使用。

客户端应采用带随机抖动（jitter）的指数退避策略，而不是立即重试。随机抖动可以避免大量客户端在限流窗口重置时同时发起重试，从而再次给服务造成压力。

应记录被拒绝的请求、限流决策、响应状态码、请求延迟和资源消耗情况。

按照接口、账号、API Key 和来源网络等维度监控流量。对于流量突然增长、身份认证反复失败、异常数据导出，以及基础设施或第三方服务费用持续上升等情况，应及时触发告警。

还应通过压力测试验证限流配置，并随着业务访问量的变化定期调整阈值。

总结

防止 API 被恶意刷取，需要采用多层防护措施，包括基于身份的限流、单次请求资源消耗限制、机器人流量识别、基础设施保护和持续监控。

仅依靠 IP 封禁和 CAPTCHA 并不足以保护 API。每个接口都应该明确限制请求频率和单次请求的处理成本。

阅读原文：原文链接