防止 API 爬取与滥用：身份、行为信号与流量控制

防止 API 爬取并不等于阻止所有自动化客户端。搜索引擎爬虫、监控、无障碍工具、合作伙伴集成和客户脚本都可能是合法调用。真正的目标是提高滥用自动化的成本并使其可观察，同时保留经过批准的使用方式。

应从被滥用的业务操作入手，例如批量抓取、撞库、囤积库存、批量注册、枚举或高成本搜索，而不是先猜测某个客户端是不是机器人。将网关控制与应用中的身份、行为和交易规则结合起来。IP 地址和 User-Agent 都是有用信号，但都不能证明客户端背后的操作者是谁。

核心要点

• 选择控制措施前，先定义需要保护的资源和滥用后果。
• 按路由、已认证身份、账号和粗粒度网络上下文实施相互独立的限制。
• 高影响决策应依据一段时间内的行为，而不是单个请求头或一次请求。
• 优先采用记录、降低配额、发起挑战或仅阻断特定操作等分级响应。
• 衡量误报、绕过率、上游成本和合法流程完成率，而不只是拦截请求数。

按工作流建立滥用模型

OWASP 机器人管理与反自动化备忘单分别讨论爬取、撞库、抢购、批量注册、盗刷等自动化威胁，因为每一类都需要不同的证据和控制。

一个普通请求可能因为重复、协同或业务上下文而变成滥用。应用可能知道十个不同账号共用同一支付工具，网关通常不知道。此类交易规则应保留在拥有必要数据和处置职责的系统中。

建立分层信号

使用多类范围明确的信号：

• 已验证身份： API 消费者、用户、工作负载、租户、权益和 Token Audience。
• 网络上下文： 可信客户端地址、ASN、地理位置、代理信誉和连接特征。
• 请求行为： 路由序列、速率、并发、分页深度、查询重复和结果量。
• 客户端上下文： 会话时长、设备或 TLS 信号，以及声明的 User-Agent，并完成隐私审查。
• 业务结果： 登录是否成功、库存是否预留、账号是否创建、导出大小、支付或退款模式。

不要静默信任来自公网客户端的身份请求头。可信边缘或认证组件必须删除客户端值，再创建经过认证的新上下文。应尽量减少指纹数据，记录收集目的，限制访问，并为原始信号设置较短的留存期。

使用相互独立的流量控制

一个组合键可能造成绕过。登录限流如果只使用 IP + username，攻击者只要轮换任意一个维度就能获得新桶。应分别评估账号、来源、租户和路由等限制，并要求所有适用策略都通过。

根据目标选择作用范围：

• 使用实例本地保护线保护每个网关进程；
• 当一个身份或租户预算必须覆盖整个集群时，使用共享计数器；
• 当限制依赖记录、支出、结果大小或业务状态时，在应用侧实施配额；
• 对高成本操作同时限制并发和成本，而不只是请求数。

返回稳定、通用的拒绝语义。不要透露过多具体桶或检测规则信息，以免攻击者据此调整工具。

在正确边界应用 APISIX 控制

Apache APISIX 3.18 的 limit-count支持固定或滑动请求窗口，以及本地或 Redis 计数器。以下示例按已认证消费者名称应用共享滑动窗口配额：

1{
2  "uri": "/v1/catalog/search",
3  "plugins": {
4    "key-auth": {},
5    "limit-count": {
6      "count": 300,
7      "time_window": 60,
8      "window_type": "sliding",
9      "key_type": "var",
10      "key": "consumer_name",
11      "policy": "redis",
12      "redis_host": "redis.internal",
13      "redis_port": 6379,
14      "redis_ssl": true,
15      "redis_ssl_verify": true,
16      "redis_password": "<managed-secret>",
17      "allow_degradation": false,
18      "rejected_code": 429,
19      "rejected_msg": "Request quota exceeded"
20    }
21  },
22  "upstream": {
23    "type": "roundrobin",
24    "nodes": {"catalog.internal:8080": 1}
25  }
26}

这些数值只是示例，不是生产建议。实际阈值应根据合法负载分布和受保护上游容量确定。此片段假设 Redis 提供 TLS，且其证书受到 APISIX 信任。应通过获准的密钥流程提供密码，隔离 Redis 网络路径，并保持证书验证开启。Redis 不可用时，allow_degradation: false 会让该策略保持故障关闭；请针对每条路由决定行为并完成测试。

APISIX 还提供 ua-restriction，可按 User-Agent 模式配置允许列表或拒绝列表。它可以阻止已明确识别的爬虫，也可要求受控集成路由使用获准的客户端标识。但它不是强机器人识别：客户端可以省略或修改请求头，宽泛规则也可能误伤无障碍、研究、监控和合作伙伴工具。

在网关核心之外增加行为决策

如果决策需要会话历史、设备信誉、跨路由序列或交易结果，应使用具有明确契约的专用风险或授权服务。只发送必要属性，并定义：

• 分数或规则版本和原因码；
• 允许、观察、挑战、降级或阻断等操作；
• 超时和服务不可用时的行为；
• 决策 TTL 和重放保护；
• 隐私、留存和申诉要求；
• 回滚与紧急绕过负责人。

除非延迟与可用性预算已经包含相关开销，不要让昂贵的模型或供应商调用进入低风险路径。也不要让第三方分数变成无法解释的永久账号处罚。

优先采用分级响应

对于已确认的滥用，硬阻断是合理手段，但不适合所有不确定信号。分级策略可以：

1. 观察并标记低置信度流量；
2. 降低配额或减少高成本响应内容；
3. 要求重新认证、MFA 或无障碍挑战；
4. 延迟高成本操作或将其放入队列；
5. 阻断敏感操作，同时保留账号恢复或普通浏览能力；
6. 暂停已确认的账号或凭证并开展调查。

挑战会引入摩擦和无障碍问题。应在证据表明敏感操作需要升级验证时使用，而不是覆盖每个请求。对于无法完成视觉挑战的用户，应提供替代路径。

让决策可观察、可回滚

记录请求 ID、受保护路由、可信主体、粗粒度网络上下文、规则或模型版本、信号类别、决策和结果。对凭证和个人数据进行脱敏，并监控：

• 各客户端群体的合法成功率和放弃率；
• 挑战通过率与失败率；
• 后续被撤销或申诉的阻断；
• 各身份和路由的请求量、数据量与成本；
• 规则命中和置信度分布；
• 攻击期间的源站负载和业务损失；
• 检测器延迟、超时和不可用行为。

每条规则都需要负责人、原因、开始时间、复查日期和回滚方案；临时规则还要有到期时间。无法解释或安全停用的隐藏规则本身就是可用性风险。

使用对抗流量与合法流量验证

至少测试：

1. 普通浏览器、获准爬虫、合作伙伴客户端、移动网络和无障碍工具；
2. 一个来源轮换多个账号，以及一个账号轮换多个来源；
3. 低速持续爬取、深度分页、查询变形和并行会话；
4. 在授权环境中模拟分布式住宅或云代理流量；
5. 缺失、普通和伪造的 User-Agent；
6. 计数存储、风险服务和边缘信号发生故障；
7. 挑战的无障碍性、过期、重放和恢复；
8. 在不关闭全部保护的情况下回滚误报规则。

不要对生产或第三方系统运行不受控的自动化流量。应使用获准环境、受限速率、合成身份和事故联系人。

滥用防护检查清单

• 攻击者试图取得什么业务结果？
• 哪些合法自动化客户端必须继续获得支持？
• 哪些身份已经验证，哪些字段只是信号？
• 是否按需分别限制路由、主体、来源、并发和业务成本？
• 每项决策及其数据由哪一层负责？
• 计数器或决策服务发生故障时会怎样？
• 响应是否适度、无障碍、可逆且可解释？
• 个人数据和指纹信号是否最小化并短期保留？
• 是否测试了低速持续、分布式和误报场景？

总结

API 爬取与滥用需要感知工作流的防御，而不是一个万能的机器人开关。网关适合实施可信身份控制、粗粒度网络控制、配额和决策遥测；应用及欺诈检测系统则处理网关看不到的行为和业务结果。组合相互独立的控制，采用分级响应，并持续验证绕过方式及对合法客户端的影响。

FAQ

限流能阻止 API 爬取吗？

限流能提高成本并保护容量，但分布式或低速客户端仍可能保持在简单阈值以内。还需结合身份、行为、数据量和业务规则。

API 应该阻止未知的 User-Agent 吗？

公共路由通常不应这样做。该请求头很容易伪造，宽泛阻断也可能破坏合法工具。可将其作为一个粗粒度信号，或仅用于严格受控的集成路由。

CAPTCHA 是 API 网关控制吗？

它通常属于应用或身份升级验证流程。网关可以转发并执行挑战结果，但挑战本身需要无障碍体验、过期机制、重放保护和恢复流程。

后续步骤

设计分布式限流，验证可信 IP 策略，并把滥用场景纳入 API 网关安全扫描体系。