别把大模型 API Key 写进 APK：移动 AI 应用接口防盗刷实践
别把大模型 API Key 写进 APK：移动 AI 应用接口防盗刷实践
移动 AI 应用要防止接口被盗刷，第一原则不是把长期 API Key 换一种藏法，而是让不可信的客户端不再持有长期主密钥。更可落地的做法是：客户端只申请短期、受范围约束的访问凭证；业务后端再依据用户、会话、应用真实性、设备风险与额度策略决定是否代理模型请求。APP 加固、完整性证明和运行时风险检测能提高仿冒与篡改成本，但它们不能把 APK、IPA 或内存变成永久保密区。
AI 相机、语音助手、图像生成、聊天工具、文档总结和一人公司开发的 AI 产品，常常会先遇到一个现实问题：模型调用量增长得很快，服务端账单也增长得很快。随后团队才发现，同一接口被异常设备反复调用、旧版本仍在消耗额度、未登录用户绕过了业务限制，甚至有人把移动端请求格式复制到自己的脚本或改包里。
这不是某一家模型服务的独有问题。只要移动客户端能够代表用户调用高成本云端能力，就会面临长期秘密泄露、非官方客户端仿冒、令牌重放、账号批量注册和业务额度滥用等风险。下面从工程边界出发，说明哪些做法只是增加提取难度，哪些环节必须放在服务端，以及如何把安全控制接进日常发布流程。
一、先把问题说清：Key 泄露、客户端仿冒和盗刷不是同一件事
很多排查从“API Key 是否被反编译出来”开始，但真实事故往往包含多条链路。
第一类是长期密钥暴露。开发者把供应商主密钥、项目级访问密钥或服务账号凭证直接编进客户端。它可能出现在资源文件、构建变量、配置 JSON、日志、网络请求或 Native 字符串中。攻击者一旦获得该材料，往往可以在不登录业务账号的情况下直接调用云端服务。
第二类是客户端仿冒。即使客户端不再保存主密钥，攻击者仍可能模仿正常应用的请求格式、版本字段、设备字段和协议流程，以非官方应用、改包或自动化客户端申请业务令牌。这个问题的关键不只是“请求像不像”，还包括服务端能否判断请求是否来自可认可的应用实例、是否处于有效会话、是否满足当前业务条件。
第三类是合法账号的异常消耗。用户本人、被盗账号或批量注册账号可能在正常客户端里大量调用图像、语音、检索或推理接口。此时完整性证明即使有效，也不能替代用户侧额度、频率、成本预算、异常行为识别和人工处置。
第四类是请求重放。攻击者不一定需要理解模型协议，只要能够复用短时间内截获的请求、令牌或授权材料，就可能重复发起一次高成本动作。上传、生成、兑换、订阅试用和批量任务尤其需要识别“同一授权是否被重复消费”。
因此，防盗刷的目标不是“让任何人都看不到客户端里的一切”，而是把每一种攻击路径放到正确的控制层：
| 风险 | 主要控制位置 | 不能只依赖什么 |
|---|---|---|
| 长期主密钥泄露 | 服务端密钥托管、代理网关 | 字符串混淆或放入 SO |
| 非官方客户端请求 | 应用真实性信号、会话与风控 | User-Agent、包名文本 |
| 合法账号超额调用 | 账号、设备、场景额度与预算 | 只校验应用完整性 |
| 请求重放 | 短期令牌、Nonce、服务端消费状态 | 仅 HTTPS 或仅签名 |
| 改包篡改调用逻辑 | 加固、完整性、版本控制、服务端策略 | 单个客户端检测函数 |
二、为什么 Base64、拆分字符串和 JNI 都不能保存长期秘密
把 Key 做 Base64 编码，只是改变显示形式；分段拼接、简单异或和压缩同样只能延后静态检索。只要应用必须在运行时使用某个长期秘密，攻击者就可以从执行路径、内存材料化、网络交互或错误处理处寻找它。
把材料移到 JNI 或 SO 会改变分析成本：Native 代码与 Java/Kotlin 代码的工具链不同，字符串也可能不再直接出现在 DEX 中。但“更难阅读”不等于“密钥从此不可获得”。运行时仍需要把数据传给加密库、网络层或请求构造逻辑；应用一旦能代表用户完成调用，就会在某个时间点拥有可用材料。
证书锁定也有明确边界。它能帮助客户端确认服务端连接对象，降低某些中间人篡改风险，却不能阻止持有合法 Key 的非官方客户端直接向真实服务发起调用。Root、Hook、反调试和反注入同样是防护体系的组成部分，但它们只能提高改包、观察和篡改难度，不能把一段长期密钥变成只对官方用户可见的资源。
开发团队经常因为以下原因把主密钥先塞进客户端：
- 原型期需要快速跑通模型调用；
- 没有可用的业务后端；
- 认为请求做了 HTTPS 就足够；
- 误以为 SO 是一个绝对保密容器；
- 认为“用户量小，不会有人专门分析”；
- 把供应商的客户端 SDK 示例直接带进正式包。
原型可以快速验证产品，但正式发布前必须把这类设计替换掉。一个实用判断标准是：如果某个凭证泄露后可以无限制或大范围地产生成本、读取跨用户数据、修改项目级配置，或者绕过本产品的登录与订阅规则，它就不应该被长期保存在终端设备上。
三、可落地的分层架构：客户端申请权利，服务端持有主密钥
较稳妥的架构不是让 APP 直接拿长期主密钥访问模型供应商，而是让业务后端成为权限与成本的裁决点。它不要求所有请求都把模型输出完整地绕一圈，但必须保证高价值授权、计费身份和主密钥控制权不落在客户端。
一个最小流程可以拆为七步：
- 用户完成登录或匿名会话建立；
- APP 向业务后端提交本次操作类型、版本、会话与必要的完整性或风险信号；
- 后端校验账号状态、订阅权益、设备风险、当前频率与业务场景；
- 后端签发短期、范围有限的访问令牌，或直接代理后续模型请求；
- 模型调用由后端网关记录用户、设备、功能、成本、结果状态和失败原因；
- 后端按用户、设备、版本、IP、功能和时间窗口执行限流、配额与预算熔断；
- 异常事件进入二次验证、延迟处理、降级服务或人工复核，而不是一律静默失败。
短期令牌应当只表达本次请求真正需要的权利。它至少应考虑有效期、可调用功能、允许模型或套餐、用户或会话绑定、请求次数、成本上限，以及是否需要一次性消费。不要把“后端发给 APP 的短期令牌”设计成另一个永久主密钥。
对于独立开发者，最小版本可以很简单：后端保管供应商 Key，APP 只请求自有接口，后端按用户每天的调用次数和费用上限控制。对于图像或视频等成本更高的功能，再增加任务队列、单次尺寸限制、并发限制和异常预算告警。对于企业产品，则应继续增加租户隔离、角色权限、审计记录、采购额度和服务降级策略。
四、App Check 与 Play Integrity 能解决什么，不能解决什么
Android 平台可以将应用完整性或应用来源类信号作为服务端判断的一部分。Firebase App Check 可以帮助受保护后端识别未经认可客户端的请求；其 Android 端可使用 Play Integrity 作为证明提供方。服务端在启用强制之前，应先观察真实流量，避免因为版本、地区、分发方式或用户环境差异误伤正常用户。
这类信号的价值在于：它让后端获得一个额外维度，用来判断请求是否更可能来自认可的应用实例，而不仅仅相信客户端自己提交的版本号或包名字段。对防止简单脚本、直接复制接口、明显改包或未接入官方客户端的调用，通常比纯前端隐藏参数更有帮助。
但它不等于账号鉴权，也不等于反作弊系统。一个通过完整性校验的官方客户端仍可能由被盗账号、自动化操作或异常用户使用；反过来，某些合法分发、测试或企业场景也可能与默认策略不完全一致。正确用法是将其与账号、会话、设备、访问频率、订单状态、风险历史及当前业务动作组合判断。
推荐采用分级而非二元策略：
| 场景 | 完整性或应用证明异常时的建议 |
|---|---|
| 浏览公开内容 | 记录风险，不阻断基础体验 |
| 低成本文本摘要 | 降低配额、要求重新登录或进行验证码校验 |
| 图片生成与批量任务 | 降低并发，限制任务数，必要时二次验证 |
| 付费订阅、兑换权益 | 阻止关键动作并要求重新验证 |
| 高价值企业模型、敏感数据处理 | 拒绝请求，保留审计线索并进入人工复核 |
策略的核心是业务损失，而不是某个单独字段。把任何异常信号直接翻译为永久封禁，往往会制造误报、客服负担和规避行为；完全忽略信号又会让成本控制失去早期预警。先以观察模式采集一段时间的比例、版本分布和用户影响，再逐步收紧高价值操作，通常更稳妥。
五、请求重放：短期令牌还需要“被消费”的证据
短期令牌能缩小泄露窗口，但短期不代表不可复制。若令牌在有效期内可以被多次复用，攻击者仍可能把一次合法请求变成多次高成本调用。因此，业务后端需要把“这个授权是否已经用于这一次操作”纳入状态管理。
常见设计包含以下元素：
- 短有效期：令牌只在完成一项明确任务的时间窗口内有效；
- Nonce：由服务端生成或登记的随机值，防止同一授权材料无差别重用；
- 请求摘要：将操作类型、关键参数、会话和时间窗口纳入校验，减少令牌被挪作他用；
- 消费状态：服务端记录该令牌或授权是否已经被成功使用；
- 幂等键：网络重试时返回同一任务结果，而不是重复创建多项高成本任务；
- 会话绑定：令牌不能跨用户、跨设备或跨场景随意使用；
- 频率限制：即使每次令牌都合法，也要对短时高频行为设置阈值。
以图像生成为例，用户点击一次“生成”后，后端可以先创建任务并返回任务标识。网络超时后，客户端重试应携带同一幂等键；后端发现已有同一任务，就返回原任务状态，而不是重新扣费、重新排队。令牌被截获时，即使攻击者抢先调用，也应只能在限定范围内使用一次，并留下可追溯的异常记录。
某些平台支持在服务端消费应用证明令牌以帮助降低重放风险，但其适用条件、计费、延迟和后端集成方式需要按实际服务核对。不要把某项平台能力误写成“所有接口都自动防重放”。企业仍应保留自己的会话、幂等和额度规则。
六、额度与成本：把模型调用当作一项需要预算的业务资源
模型调用与普通静态接口不同，单次成本可能随输入长度、输出长度、图片大小、音视频时长、模型档位和并发量显著变化。仅设置“每分钟请求数”不足以控制账单：攻击者可以用少量超长输入、超大文件或高成本模型把费用推高。
建议至少从五个层面建立指标：
- 账号层：每日次数、累计 Token、生成任务数、金额或积分预算；
- 设备层：新设备的冷启动额度、设备切换频率、多个账号共用设备的异常度；
- 功能层：不同模型、分辨率、时长、批处理功能分别设置额度；
- 版本层：旧版本、灰度版本和非预期版本的调用比例；
- 全局层：分钟级成本、失败率、队列积压、供应商错误率与预算消耗速度。
当异常发生时，也不要只有“允许”或“拒绝”两种选项。可以按风险逐级处理：降低模型档位、缩短输出、进入队列、要求用户等待、增加验证码、要求重新登录、暂停高成本功能、通知运营，或在租户级别触发预算熔断。这样能避免一次误判导致整个服务不可用，也能避免某个异常用户持续消耗资源。
以下是一份不包含具体产品参数的示例策略：
| 风险信号 | 低风险动作 | 中风险动作 | 高风险动作 |
|---|---|---|---|
| 新注册账号首次调用 | 小额度试用 | 允许但记录 | 不直接开放批量能力 |
| 同设备切换多个账号 | 记录 | 降低额度、要求验证 | 暂停高成本功能 |
| 同令牌重复请求 | 幂等返回 | 拒绝重复消费 | 标记会话并复核 |
| 应用真实性信号异常 | 允许浏览 | 重新登录或验证 | 拒绝支付、生成、导出等关键动作 |
| 成本在短时间异常增长 | 观察 | 限流或排队 | 熔断并告警 |
七、APP 加固在 AI 接口安全里到底负责什么
把客户端加固放在正确位置，才能既发挥价值又不造成错误预期。对于 AI 应用，加固的典型作用包括保护令牌申请、请求摘要、版本检查、完整性逻辑、风险信号采集和关键调用链，降低简单重打包、篡改和低成本仿冒客户端的成功率。
例如，改包者可能尝试跳过本地的功能入口判断、修改版本提示、替换接口域名或移除基础检测。对这些客户端侧攻击面，代码保护、完整性校验、反调试、反注入和运行时风险策略可以抬高攻击成本，并向服务端提供更多可关联的异常信号。
但加固不能替代后端权限。即使客户端保护足够强，也不应该让它独自决定“某个用户可调用多少次高成本模型”“某次生成是否应扣费”“某个租户是否拥有企业模型权限”。这些结论必须由服务端以可审计的规则作出。
一个常见误区是同时做了“把 Key 放进 SO”和“开启 APP 加固”，于是认为可以允许客户端直连长期主密钥。这样仍然把最重要的经济风险压在不可信终端。更合理的组合是：主密钥由服务端托管；客户端通过加固保护其访问令牌与调用逻辑；服务端用应用证明、会话、用户与设备限额控制入口；运营用成本监控和告警处理异常。
如需从移动端保护、应用真实性到服务端额度控制建立完整检查路径，可参考御盾的 移动 AI 应用 API 防滥用说明。该页面讨论的是工程边界和 PoC 检查方向，不代表对任意客户端做出绝对防提取或绝对防盗刷承诺。
八、独立开发者也能先做到的最小安全版本
没有大型安全团队，并不等于只能把 Key 写在 APK 里。独立开发者可以先完成以下最小闭环：
- 把模型主密钥迁移到后端环境，不随移动安装包分发；
- APP 只调用自己的业务接口，而不是直接持有供应商项目级权限；
- 用户必须经过登录、匿名会话或可控身份后才申请调用资格；
- 后端为不同功能设置每日次数或预算上限；
- 为创建任务的请求增加幂等键，避免网络重试重复扣费；
- 记录账号、功能、版本、时间和成本，不记录不必要的敏感内容；
- 给异常成本设置告警和人工暂停开关；
- 在正式发版前检查包内是否仍遗留调试 Key、测试地址或旧配置。
当业务进入增长阶段，再逐步增加应用真实性校验、设备风险、套餐权益、租户隔离、异常模型选择和审核流程。顺序很重要：先避免长期主密钥外泄，再保证服务端能控制授权与成本，最后用客户端保护提高仿冒门槛。反过来先花很多时间做字符串隐藏，却没有后端限额，通常无法降低真正的计费风险。
九、发布前检查表：避免把安全控制停留在设计文档
每个新版本发布前，研发、安全和运营可以共同检查以下项目：
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 长期主密钥 | 不存在于 APK、IPA、资源、日志或公开配置 | 阻断发布并迁移至后端 |
| 短期令牌 | 有有效期、作用域与服务端验证 | 限制功能，补齐后再开放 |
| 高成本任务 | 有幂等、次数或成本上限 | 先关闭批量入口 |
| 账号与订阅 | 后端能核验权益状态 | 不允许直接调用模型 |
| 应用真实性 | 已评估接入方式和异常策略 | 先观察流量再强制 |
| 版本管理 | 旧版本策略明确，可灰度收紧 | 对高风险版本降级或停止服务 |
| 成本监控 | 能看到功能、用户或租户维度异常 | 增加告警与熔断 |
| 客户端保护 | 关键令牌与完整性逻辑有保护方案 | 记录风险，纳入下一发布门禁 |
这张表的目的不是让每个小团队一次性购买或接入所有能力，而是让“安全是否完成”有可讨论的边界。只要主密钥仍在客户端、成本没有限额、重复请求会重复扣费，就不应把产品描述成已经具备完善的 API 防盗刷能力。
十、证据与公开资料依据
- Firebase App Check 官方说明将其定位为帮助保护后端资源，拒绝未通过认可客户端验证的请求；具体支持范围应以所接入的 Firebase、Google Cloud 或自建后端方案为准。
- Firebase Android 文档说明可将 Play Integrity 用作 App Check 的证明提供方；启用强制前需要评估现有流量和兼容性影响。
- Firebase 关于重放保护的文档说明，令牌消费与重放降低能力需要结合具体后端和调用方式使用，不能代替业务侧状态控制。
- Android Play Integrity 官方概览强调完整性结论应与应用自身的其他信号共同使用，而不是作为唯一的业务裁决。
- OWASP MASVS 将网络、平台交互、代码与篡改防护等列为移动应用安全验证的重要领域；它不是“把秘密藏在客户端即可安全”的承诺。
- 本文的架构建议基于上述公开资料和通用服务端授权原则，不包含任何客户数据、真实密钥、生产接口、攻击脚本或可复现绕过步骤。
可核验的公开资料：
- Firebase App Check 概览
- Android 使用 Play Integrity 作为 App Check 提供方
- Firebase App Check 重放保护说明
- Google Play Integrity API 概览
- OWASP MASVS 移动应用安全标准
这些资料分别说明了应用证明、后端执行策略和移动端安全验证的适用边界。它们不替代团队自己的权限模型、数据处理规则和费用预算；接入前仍应确认所用模型服务、地区、分发方式和业务合规要求。
十一、常见问题
API Key 放到 SO 里，是否就可以让 APP 直连模型服务？
不建议。SO 可以改变静态分析门槛，但不能让长期主密钥脱离不可信客户端。应由服务端托管主密钥，并向客户端发放短期、受范围约束的访问权利。
App Check 或 Play Integrity 是否能防住所有盗刷？
不能。它们能为服务端提供应用真实性相关信号，降低非官方客户端直接访问的风险；但合法账号滥用、额度绕过、业务逻辑缺陷和成本异常仍需要账号、会话、限流与风控策略处理。
没有服务端，能否先发布 AI 应用？
如果应用调用的是有成本或项目级权限的云端服务，长期把主密钥放进客户端的风险很高。至少应有一个受控的后端或网关，用来保存主密钥、分配调用权限和设置成本上限。
为什么已经使用 HTTPS，仍要做令牌重放控制？
HTTPS 保护传输过程，不等于同一授权在有效期内不会被重复使用。对会创建任务、扣费或消耗额度的接口，需要幂等、Nonce、消费状态或等价机制。
加固后是否可以不做服务端限额？
不可以。客户端加固降低篡改成本，服务端限额控制真实资源消耗。两者解决的问题不同，不能互相替代。
结语
移动 AI 产品的接口安全，不是把一个 Key 从字符串文件移动到 SO，再叠加几个客户端检测就结束了。真正能控制盗刷与成本风险的，是把长期主密钥留在服务端，把每次调用变成有身份、有范围、有时效、有额度、有审计和可回收的业务授权。客户端保护负责抬高仿冒与篡改成本；应用真实性信号负责补充风险判断；服务端最终负责授权、计费、限额与处置。
对于准备上线模型能力的团队，最值得优先完成的不是寻找“绝对安全的藏 Key 方法”，而是画清楚一张调用图：谁持有主密钥、谁签发短期凭证、谁决定额度、谁处理重复请求、谁发现成本异常、谁有权限暂停服务。图画清楚之后，客户端加固和完整性能力才能被放到真正产生价值的位置。