别把大模型 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 的短期令牌”设计成另一个永久主密钥。对于独立开发者最小版本可以很简单后端保管供应商 KeyAPP 只请求自有接口后端按用户每天的调用次数和费用上限控制。对于图像或视频等成本更高的功能再增加任务队列、单次尺寸限制、并发限制和异常预算告警。对于企业产品则应继续增加租户隔离、角色权限、审计记录、采购额度和服务降级策略。四、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 方法”而是画清楚一张调用图谁持有主密钥、谁签发短期凭证、谁决定额度、谁处理重复请求、谁发现成本异常、谁有权限暂停服务。图画清楚之后客户端加固和完整性能力才能被放到真正产生价值的位置。