一个15分钟前还能正常付款的账户，突然收到1.54万美元的账单。开发者撤销密钥的速度够快了——但谷歌云的计费延迟，让钱已经流了出去。
这不是某个粗心程序员的悲剧。CloudSEK的安全团队发现，32个暴露在外的谷歌API密钥，潜藏在22款安卓应用里，触达用户超过5亿。OYO酒店预订、淘宝、ELSA Speak、Google Pay for Business，这些名字你大概率用过至少一个。
问题的诡异之处在于：这些开发者没做错任何事。他们按照谷歌官方文档，把用于地图或Firebase的密钥嵌在公开应用里——谁也没想到，这些"非敏感标识符"某天会被自动升级为Gemini AI的完整凭证。
从地图密钥到AI提款机：一次静默的权限膨胀
谷歌的API架构设计，把原本隔离的服务层打通了。一个只该调用地图定位的密钥，突然被赋予了调用大模型推理的权限。CloudSEK研究员Tuhin Bose说得直白：「这不是开发者的疏忽，实现方式完全符合谷歌规定的指南。」
架构层面的这种"权限漂移"，让攻击者捡到了现成的武器。他们不需要破解，只需要扫描公开代码仓库和APK文件，找到那些躺着睡觉的旧密钥，然后对着Gemini API疯狂发送推理请求。
一位日本公司的防火墙配置了IP白名单，照样被刷掉12.8万美元。墨西哥一个小团队在48小时内账单暴涨455倍，达到8.2万美元——这差不多是很多人两年的工资。
计费延迟：撤销密钥也挡不住的失血
那位1.54万美元账单的独立开发者，从收到警报到撤销密钥只用了几分钟。但谷歌云的计费系统存在报告延迟，撤销操作拦不住已经发生的调用。就像你关掉了水龙头，但管道里的水还在往外流。
这种延迟在常规场景下几乎无感。但当攻击者用自动化脚本以每秒数百次的频率轰炸API时，几分钟的窗口期足以制造灾难性账单。对于现金流紧绷的初创公司，这等同于猝死。
CloudSEK的扫描结果显示，暴露的密钥分布在各类应用中：酒店预订、电商、语言学习、支付工具。这些应用的共同点不是技术债严重，而是它们都遵循了谷歌曾经推荐的标准实践——把服务端密钥嵌入客户端，方便快速调用基础服务。
谷歌后来更新了密钥管理指南，强调限制API范围和定期轮换。但旧密钥的权限膨胀没有追溯性修复，数百万个已经发布的应用安装包，成了定时炸弹。
5亿用户的数据，也跟着裸奔
ELSA Speak的案例更棘手。研究人员用暴露的密钥成功访问了应用数据，确认存在实际的数据泄露风险。语言学习应用存储的可能是你的练习录音，酒店预订应用里有你的行程和支付信息，电商应用更不用说。
这些密钥的权限边界在谷歌侧变得模糊，开发者却无从知晓自己的"地图钥匙"什么时候获得了读取用户数据的额外能力。权限的静默升级，比_explicit_的漏洞更难防御——你连攻击面在哪里都不知道。
谷歌目前的应对是建议开发者启用更细粒度的API限制，并对异常用量设置预算告警。但告警的触发阈值、计费的实时性、密钥权限的历史追溯，这些基础设施层面的问题没有公开回应。
对于已经遭受损失的开发者，追回账单的流程漫长且结果不确定。那位日本公司的12.8万美元、墨西哥团队的8.2万美元、独立开发者的1.54万美元，最终由谁买单，目前未见披露。
一个值得追问的细节是：当谷歌把旧密钥的权限悄然扩展至AI服务时，是否评估过已发布应用的风险暴露面？5亿用户的安装基数，不是小数字。而那些遵循官方指南的开发者，现在需要为架构设计的副作用承担财务后果——这个责任归属，可能比技术修复更复杂。
你的应用里，有没有嵌着几年前的谷歌密钥？
热门跟贴