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 做正向校验——不符合契约的请求（未知端点、越权参数、异常字段类型）直接拒绝。Cloudflare 的 API Shield 提供 Schema validation 与 mTLS 能力，参考 WAF 能力说明。

归属与限制：API Shield 在官方文档中标明为 Enterprise-only paid add-on（企业版付费附加项）。上传 Schema 的规模有套餐配额：Free 为 5 个启用 Schema / 200 KiB 且规则动作只能 Block，Business 为 10 个 / 2 MiB，Enterprise 更高且可选择 Log 或 Block。如果用不上 API Shield，也可以先用 WAF 的 Application Profiles / Schema Validation 做「先检测、后缓解」，再视效果决定是否升级。

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

好消息：mTLS 本身并不贵——官方文档写明 所有套餐都能用 Cloudflare 托管 CA 配置 mTLS；只有「自带 CA（BYO CA）」限 Enterprise，且最多 5 个。所以 Edge-side mTLS 通常是这套方案里最容易先落地的一层。

第三步：识别非人类流量。 Cloudflare 的 Bot 防护按套餐分档（详见下表）。Bot Management 会结合 TLS 指纹、请求行为序列、HTTP 异常特征等输出信号；Enterprise 订阅后可拿到 1–99 的细粒度 bot score，其中 1 表示高度确定是自动化流量，99 表示高度确定是人类（方向与直觉相反，写规则时最容易搞错）。对画像可疑但不确定的请求下发 JS 挑战或托管挑战，而不是直接封死。

第四步：分层限流与配额。 用 Cloudflare Rate Limiting rules 按路径、请求头等维度限流，而不是只按 IP。但有两个技术限制必须提前算进去：

• 计数器按数据中心独立累计。 Cloudflare 明确说明不支持全网全局计数器，每条规则默认带上 cf.colo.id（数据中心 ID）作为计数维度；同一地理位置的多个数据中心会共享，跨地区则不会。所以「每分钟 100 次」在流量分散到多个机房时，实际到达源站的可能数倍于此。想要严格的全局上限，必须在应用层补一道。
• 计数维度受套餐限制。 Free / Pro 的规则只能按 IP 计数；是否需要按请求头、JSON 正文字段、JWT 声明或表单字段计数，取决于套餐与是否购买了 Advanced Rate Limiting（详见下表）。不要把「按 body 里的 tenant_id 计数」当成默认可用能力写进方案。
• 规则条数也有限额：Free 1 条、Pro 2 条、Business 5 条、Enterprise 通常 100 条（取决于合同）。这意味着「每类接口一条规则」的思路在低套餐上根本放不下，必须先做优先级排序。

第五步：异常流量分析。 监控三个信号：某一端点突然占总流量大头、401/403/429 比例突增、单位 Token 成本与调用量的关系异常。这三条往往比总 QPS 更早报警。注意 Free 套餐的 Security Events 只有采样日志，做告警要看的出不来。

第六步：合计配额到应用层。 边缘限流是「尽力而为」的近似控制，Cloudflare 官方文档也写明限流规则不是用来保证精确请求数的，且检测到超限到实施动作之间可能有几秒延迟。真正的硬性成本上限必须放在你的应用层，例如用集中式计数器在每次推理前扣减额度。

套餐可用性对照

下列限制整理自 Cloudflare 官方文档（2026-10 版本），实际以控制台可见项为准。

能力	Free	Pro	Business	Enterprise
Bot 防护形态	Bot Fight Mode	Super Bot Fight Mode	Super Bot Fight Mode（含 Likely automated 分组）	Bot Management（需订阅）
细粒度 bot score 1–99	不可用	不可用	仅 Bot Analytics 分组	可用于自定义规则与 Workers
限流规则条数	1	2	5	100（取决于合同）
限流计数维度	仅 IP	仅 IP	IP 及 IP with NAT support	增加 Query / Host / Header / Cookie / ASN / Country / Path / JA3-JA4
请求正文、JSON 字段、JWT 声明计数	不支持	不支持	不支持	需 Advanced Rate Limiting（付费附加项）
复杂度/成本维度限流	不支持	不支持	不支持	Advanced Rate Limiting 专属
计数周期上限	10 秒	1 分钟	10 分钟	最长 65,535 秒
WAF 自定义规则条数	5	20	100	1,000
mTLS（Cloudflare 托管 CA）	可用	可用	可用	可用（自带 CA 上限 5 个）
API Shield（含 Schema 校验等）	—	—	—	Enterprise 付费附加项

Cloudflare 能力 vs 应用层职责

Cloudflare 能确认「调用形式合法、来源可信、频率正常」，但下面几件事它做不到，也不该指望它做：

事项	边缘产品能给的	应用层必须做的
全局额度上限	按数据中心近似计数	集中式计数器，扣减后落库，跨机房一致
单次请求成本	复杂度计分（需 ARL + 源站返回分）	按 token / 分辨率 / 时长折算成本单位
业务授权判断	来源与凭据校验	「这个租户这次能不能调用这个接口」
异步任务治理	提交接口限流	队列并发、未完成任务上限、超时回收
事后追责	边缘日志与 Logpush	可回放的调用链审计与一键吊销
成本对账	AI Gateway 的 token 与成本观测	与实际账单相核对，产出成本归因

需要集中式计数时，可参考 Durable Objects 做单点序列化计数；模型调用的统一观测可先看 AI Gateway。

最小可用配置清单

维度	建议动作	说明
未登记端点	直接 403	防未知 API 探测与影子 API
超出 Schema 的请求	400 / 403	防参数遍历与注入；注意低套餐规则动作只能 Block
单凭据每分钟请求数	超过阈值返回 429	按业务毛利倒推阈值，并预留多机房放大倍数
单 IP 新建账号 / 会话数	触发 Turnstile 或托管挑战	针对注册薅额度，参考 Turnstile
Bot 信号可疑但不确定	挑战而非直接阻断	降低误伤搜索引擎与合作方
每日/每月总额度	应用层硬闸门	边缘只能近似限流，这里才是止损线

边界与不适用情况

• 纯 B2B 机器调用场景（第三方服务器对接）没有浏览器指纹可用，Bot 信号有限，应把重点放在 mTLS + Schema + 配额三件事上。
• 高单价推理接口的限流阈值必须结合毛利倒推：一次文生图调用成本远高于一次查询，照搬网关默认 QPS 会让防护形同虚设。要真正按成本计数，需要 Advanced Rate Limiting 的复杂度计分能力，且源站要在响应头里返回 1–1,000,000 的分值。
• IP with NAT support 不是免费的午餐：它依赖 Cookie 识别独立访客，清理 Cookie 或隐私模式的访客会共用同一个计数桶，在 NAT 密集场景可能造成误判。登录、支付等关键接口应叠加路径或请求头维度，不要单独依赖它。
• 涉及个人信息或跨境调用时，访问日志与请求体镜像要做脱敏后再长期留存，否则安全措施会引入新的合规风险。
• 如果你的 API 只是「防君子」：上述五层全上通常过度设计。最低可行组合是「mTLS 或强凭据 + 应用层总额度 + 基本边缘限流」，其余等发生事故再加。

常见问题

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

想按 API Key 限流，需要什么套餐？ 若把 Key 放在请求头里作为计数维度，通常需要 Business 以上或 Enterprise 含应用安全的合同；若还要按正文里的 JSON 字段或 JWT 声明计数，就需要 Advanced Rate Limiting。低套餐的替代做法是：用路径 + IP 做粗粒度边缘限流，把「按 Key 计费和限额」放到应用层。

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

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

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

相关阅读

• AI SaaS 如何控制 API 调用成本和异常流量？
• AI 应用如何防止用户批量注册和薅免费额度？
• API Key 泄露后如何防止接口被滥用？
• 如何识别正常用户、恶意爬虫和自动化 Bot？