别把大模型 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 将网络、平台交互、代码与篡改防护等列为移动应用安全验证的重要领域；它不是"把秘密藏在客户端即可安全"的承诺。
本文的架构建议基于上述公开资料和通用服务端授权原则，不包含任何客户数据、真实密钥、生产接口、攻击脚本或可复现绕过步骤。

可核验的公开资料：

这些资料分别说明了应用证明、后端执行策略和移动端安全验证的适用边界。它们不替代团队自己的权限模型、数据处理规则和费用预算；接入前仍应确认所用模型服务、地区、分发方式和业务合规要求。

十一、常见问题

API Key 放到 SO 里，是否就可以让 APP 直连模型服务？

不建议。SO 可以改变静态分析门槛，但不能让长期主密钥脱离不可信客户端。应由服务端托管主密钥，并向客户端发放短期、受范围约束的访问权利。

App Check 或 Play Integrity 是否能防住所有盗刷？

不能。它们能为服务端提供应用真实性相关信号，降低非官方客户端直接访问的风险；但合法账号滥用、额度绕过、业务逻辑缺陷和成本异常仍需要账号、会话、限流与风控策略处理。

没有服务端，能否先发布 AI 应用？

如果应用调用的是有成本或项目级权限的云端服务，长期把主密钥放进客户端的风险很高。至少应有一个受控的后端或网关，用来保存主密钥、分配调用权限和设置成本上限。

为什么已经使用 HTTPS，仍要做令牌重放控制？

HTTPS 保护传输过程，不等于同一授权在有效期内不会被重复使用。对会创建任务、扣费或消耗额度的接口，需要幂等、Nonce、消费状态或等价机制。

加固后是否可以不做服务端限额？

不可以。客户端加固降低篡改成本，服务端限额控制真实资源消耗。两者解决的问题不同，不能互相替代。

结语

移动 AI 产品的接口安全，不是把一个 Key 从字符串文件移动到 SO，再叠加几个客户端检测就结束了。真正能控制盗刷与成本风险的，是把长期主密钥留在服务端，把每次调用变成有身份、有范围、有时效、有额度、有审计和可回收的业务授权。客户端保护负责抬高仿冒与篡改成本；应用真实性信号负责补充风险判断；服务端最终负责授权、计费、限额与处置。

对于准备上线模型能力的团队，最值得优先完成的不是寻找"绝对安全的藏 Key 方法"，而是画清楚一张调用图：谁持有主密钥、谁签发短期凭证、谁决定额度、谁处理重复请求、谁发现成本异常、谁有权限暂停服务。图画清楚之后，客户端加固和完整性能力才能被放到真正产生价值的位置。