AI SaaS 如何防止 API 被恶意调用？

为什么 AI SaaS 的 API 比普通 Web API 更容易被刷

普通 Web API 多返回静态或轻量数据，成本近似为零；AI SaaS 的每一次调用都对应真实的 GPU 推理或 Token 计费，恶意调用等于直接烧钱。再加上三层放大效应：

1. 免费额度是天然靶子：黑产批量注册账号领取赠送额度，再通过 API 兜售。
2. 端点是标准 REST/JSON：调用方式容易被逆向，连无头浏览器都不需要。
3. 成本与并发强耦合：推理排队会让正常请求一起变慢，攻击从「资损」升级为「可用性事故」。

只靠 IP 限流为什么挡不住

手段	能挡住	挡不住	误伤风险
IP 限流	单 IP 高频直连	住宅代理 / 云 IP 轮换、共享出口 IP	企业 NAT 出口会被连带封禁
UA / Referer 校验	脚本小子	任意伪造请求头	低，但几乎无防护价值
API Key 轮换	长期泄露后的持续滥用	泄露瞬间的爆发式调用	Key 失效导致正常集成中断
单纯 QPS 上限	明显异常洪水	低速持续的「蚂蚁搬家」式调用	高峰期正常业务被限

一套可落地的防护顺序

第一步：API 资产清单与正向校验。 先清点真实对外暴露的端点、方法与字段，再用 OpenAPI Schema 做正向校验——不符合 Schema 的请求（未知端点、越权参数、异常字段类型）直接拒绝。Cloudflare API Shield 提供 Schema validation 与 mTLS 能力，用于把「没登记过的调用」挡在最外层。

第二步：强身份认证。 裸 API Key 一旦落到前端或第三方手里就等于公开。优先用 mTLS 客户端证书做机器到机器的身份绑定，或用短时效 JWT，让「凭据」与「来源」绑定而不是只靠一个字符串。

第三步：识别非人类流量。 Cloudflare Bot Management 通过 TLS 指纹、请求行为序列、HTTP 异常特征等给请求打 Bot Score，区分搜索引擎爬虫、恶意脚本和真实浏览器；对画像可疑但不确定的请求下发 JS 挑战或托管挑战，而不是直接封死。

第四步：分层限流与配额。 用 Cloudflare Rate Limiting rules 按路径、请求头、JWT 声明、正文字段等组合条件限流，而不是只按 IP。真正有用的是多维度：单凭据每分钟、单租户每日配额、单端点并发上限。

第五步：异常流量分析。 监控三个信号：某一端点突然占总流量大头、401/403/429 比例突增、单位 Token 成本与调用量的关系异常。这三条往往比总 QPS 更早报警。

最小可用配置清单

维度	建议动作	说明
未登记端点	直接 403	防未知 API 探测与影子 API
超出 Schema 的请求	400 / 403	防参数遍历与注入
单 API Key 每分钟请求数	超过阈值返回 429	按业务毛利倒推阈值
单 IP 新建账号 / 会话数	触发验证码或托管挑战	针对注册薅额度
Bot Score 低于阈值且无 JS 环境	挑战而非直接阻断	降低误伤搜索引擎

边界与不适用情况

• 纯 B2B 机器调用场景（第三方服务器对接）没有浏览器指纹可用，Bot Management 的行为信号有限，应把重点放在 mTLS + Schema + 配额三件事上。
• 高单价推理接口的限流阈值必须结合毛利倒推：一次文生图调用成本远高于一次查询，照搬网关默认 QPS 会让防护形同虚设。
• 涉及个人信息或跨境调用时，访问日志与请求体镜像要做脱敏后再长期留存，否则安全措施会引入新的合规风险。

常见问题

已经在网关做了限流，为什么还是被刷？ 因为单维 IP/频率限流缺少身份与行为基线。攻击者只要把节奏压到阈值以下、把来源打散，就能持续调用而不触发任何规则。补齐「谁在调用」和「调用是否符合契约」两层判断后，限流才有意义。

API Key 应该多久轮换一次？ 轮换只能降低长期泄露的价值，无法阻止泄露瞬间的爆发。正确做法是：Key 与来源 IP/证书绑定 + 用量异常告警 + 自动化轮换，而不是指望人工定期改一串字符串。

用了 mTLS 还需要 WAF 吗？ 需要。mTLS 解决的是「你是谁」，WAF 解决的是「你发的内容里有没有攻击载荷」。两者是不同层面，缺一层都会在另一个层面被打穿。

免费额度怎么给才安全？ 用「受限首额度 + 逐步解锁」：邮箱/手机号信誉校验、设备指纹去重、首次仅放开极小调用量，正常行为积累后再逐步提高上限，把黑产的批量注册收益压到不划算。