一次看似简单的测试，竟让一位独立开发者背负了高达1.54万美元（约10.6万元）的账单，项目也因此濒临崩溃。
近日，独立开发者vatcode在Reddit上求助，详细讲述了这次离奇的经历。他表示，自己仅仅是为一个传统应用开启了谷歌的Gemini API以测试AI功能，随后一个旧有的、公开的API密钥便被攻击者盗用，产生了巨额的非本人消费。
这绝非个案，背后暴露的是谷歌云在API密钥默认安全策略和账单报告机制上的结构性缺陷。
一次测试引发的“灾难”：旧密钥获新权限
vatcode运营着一个基于Google Firebase搭建的教育类应用。多年来，他一直使用谷歌自动生成的API密钥，例如用于地图服务的密钥。根据当时（乃至现在）的谷歌官方文档，这类密钥被视为“项目标识符”，可以安全地嵌入客户端代码。
几天前，为了给应用增加AI功能，vatcode在该Firebase项目中启用了Gemini API。问题就此发生：谷歌在启用Gemini API时，并未发出任何警告或要求重新配置密钥，就自动将项目内所有现有的、无限制的API密钥赋予了访问Gemini端点的权限。
这意味着，vatcode那些原本“安全无害”、已公开嵌入在网页中的旧地图密钥，瞬间变成了可以调用昂贵的Gemini API并产生高额费用的“高权限密钥”。攻击者很快通过爬虫获取了这些公开密钥，并利用僵尸网络发起疯狂的推理请求。
30小时延迟让“止损”沦为无用功
更令人无奈的是谷歌云的账单延迟。vatcode并非毫无防范，他设置了40美元的预算告警。当警报触发时，他反应迅速，在10分钟内完成了吊销所有密钥、关闭Gemini API等操作。
然而，他面对的是谷歌云控制台约30小时的账单统计延迟。当他完成“止损”操作时，攻击早已发生，费用已经产生，只是尚未在控制台显示。第二天，账单更新后，数字从40美元直接跳涨至15400美元。他的及时操作，在滞后的系统面前完全无效。
这是谷歌架构埋下的“陷阱”
安全公司Truffle Security在2026年2月的一份报告中明确指出，这不是开发者配置错误，而是谷歌的设计问题。报告将其核心问题总结为两点：
- 权限追溯性扩张：一个三年前创建并公开嵌入的地图API密钥，在项目启用Gemini后，会在没有任何通知的情况下，自动获得访问敏感Gemini端点的权限。
- 默认不安全配置：在谷歌云创建新的API密钥时，默认状态就是“无限制”，且对新启用的所有API（包括Gemini）立即生效。
这种“静默升级”让成千上万原本无害的公开API密钥，变成了互联网上的Gemini付费凭证。Truffle Security的扫描发现，近3000个公开的谷歌地图API密钥，都能直接调用Gemini API。
开发者如何自查与防范？
如果你是谷歌云、Firebase、Maps等服务的用户，可以按以下步骤紧急排查风险：
第一步：检查项目中是否启用了Generative Language API
进入GCP控制台，打开 APIs & Services > Enabled APIs & services，查找“Generative Language API”。需要对组织下的每个项目进行检查。
第二步：审计所有API密钥的权限
进入 APIs & Services > Credentials，重点检查两类密钥：
- 带有“无限制”警告标识的密钥。
- 在“API限制”中明确包含“Generative Language API”的密钥。
第三步：确认高风险密钥未暴露在公网
检查上述高风险密钥是否被嵌入在前端JavaScript代码、公开的Git仓库或其他任何互联网可访问的地方。一旦发现，必须立即轮换（生成新密钥并废弃旧密钥）。
对于独立开发者和小团队而言，vatcode的遭遇不是一次普通的安全事件，而是一场关乎项目存亡的生存危机。在寻求与谷歌官方沟通解决的同时，所有使用谷歌云服务的开发者都应立刻行动起来，按照上述步骤进行安全审计，避免成为下一个受害者。 | 
发表于 3 小时前
|
查看: 2|
回复: 0
