1次操作莫名背上10.6万元账单、Gemini API密钥被盗、项目濒临崩溃，独立开发者无奈：10分钟就删除旧密钥，Google账单却延迟30小时

一次看似普通的测试操作，却引来 1.54 万美元（约 10.6 万元）的账单。这对一个刚起步的独立开发者来说，几乎是致命打击。

近日，24 岁独立开发者 vatcode 在社交媒体平台 Reddit 上发布求助帖——《Google 默认不安全的 API 密钥，加上 30 小时账单延迟，是如何毁掉我的创业项目的》。帖子中，他表示：“这绝对不是我的错”，并将矛头直指 Google，声称自己只是为了在传统应用中测试 AI 功能，便开启了 Gemini API，却意外背上了一笔并非本人使用而产生的高额费用。

他甚至直言，Google 的设计存在缺陷“可能会毁掉我的生计，以及这些年的全部努力”。

更让人不安的是，这样的情况，并非第一次发生。

一次“无意的测试操作”，换来了 1.54 万美元的账单

vatcode 运营着一款教育类应用，其核心架构完全依托 Google Firebase 搭建。

多年来，他一直使用 Google 默认生成的 API Key。简而言之，当初在 Firebase 初始化时会自动生成一些 API Key（例如 Maps API Key）。当时这些 Key 的默认状态是“无任何限制”。

按照 Google 官方文档显示，这类 Key 被视为“公共标识”，可以安全嵌入客户端代码，主要用于地图、基础认证等非计费公共服务。

它们的安全机制依赖于 HTTP Referrer 或包名限制。

来源：https://firebase.google.com/support/guides/security-checklist

vatcode 也一直按这个理解在使用，认为这类密钥安全无虞。

转折点发生在几天前，为了给自己的应用添加一个 AI 功能，vatcode 在该项目中开启了 Gemini API，想在 AI Studio 里做内部测试。

殊不知，这一步看似常规的操作，却成为灾难的开端。

vatcode 在帖子中写道，在开启 Gemini API 时，Google 并没有对这一操作发出任何警告，也未要求他重新配置密钥或创建新密钥。

结果导致原本用于公共服务的无限制旧密钥，被悄然赋予了 Gemini API 的调用权限。

很快，这个公开的 Key 被攻击者爬取了。

攻击者利用僵尸网络疯狂调用 Gemini 的服务做 AI 推理。

vatcode 眼中“安全无害”的旧密钥，瞬间变成了可产生高额费用的“付费密钥”，一场悄无声息的“薅羊毛”攻击就此展开，而他起初对此毫无察觉。

设置了预算上限警告，但 Google 30 小时的账单延迟，让及时止损成空谈

有人会问，难道开发者自己没有设置使用的上限限额吗？

事实上，vatcode 并非毫无防备，他早已在谷歌云设置了预算告警，第一档是 40 美元。

当账单达到 40 美元时，警报确实如期触发了。vatcode 也在收到告警邮件的第一时间就着手去处理了，具体包括吊销了所有密钥、在 GCP 上关闭了 Gemini API，一切做完也就花了 10 分钟不到的时间。

至此，vatcode 满心以为已经及时止损，掐断了异常消费的源头。

“但我错了”，vatcode 无奈地表示。

谷歌云的账单统计机制给了他致命一击——其计费控制台存在约 30 小时的延迟，实际的 API 调用量并不会实时显示。

第二天，等到账单面板更新时，原来 40 美元的异常消费直接飙升至 15400 美元，这期间的消费全部是攻击者在他止损前就产生的，只是被系统延迟统计，vatcode 的及时操作最终沦为无用功。

并不是个例，这是 Google 架构层面埋下的“坑”？

vatcode 的遭遇并非偶然，这也并不是一个孤立事件。

此前我们也报道过，另一位开发者RatonVaquero也遭遇过类似情况：

由于他的 Gemini API 密钥被盗用，原本每月仅约 180 美元（约 1242 元）的费用，在短短 48 小时内暴涨到 82,314.44 美元（约 56.8 万元）。对于这家只有三名开发者的小型创业团队来说，这笔突如其来的账单，几乎等同于灭顶之灾。

而对于这种问题，vatcode 称，「我逐渐意识到，自己掉进了一个由 Google 旧有架构埋下的结构性安全陷阱，而这个问题又被 Gemini API 实现中的一个危险缺陷进一步放大。」

对此，安全公司 Truffle Security 也在 2026 年 2 月的发了一篇报告进行了详解，其讲得很直白：这不是开发者自己使用不当，而是 Google 的设计问题。

报告地址：https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

正如上文提到的——多年来，Google 一直明确告诉开发者，API Key 可以安全地嵌入客户端代码中。这在当时是合理的。API Key 的设计初衷是作为项目的标识符，用于计费，并可以通过 HTTP Referer 白名单等方式进行限制（虽然这些限制可以被绕过）。它们并非设计为认证凭证。

然而，随着 Gemini 的出现，情况发生了变化。当你在 Google Cloud 项目中启用 Gemini API 时，该项目中现有的 API Key（包括那些已经嵌入在你网站公共 JavaScript 中的 Key）会在不发出任何警告、确认对话框或邮件通知的情况下悄然获得访问敏感 Gemini 端点的权限。

这带来了两个问题：

权限溯源扩张（Retroactive Privilege Expansion）。你三年前创建了一个 Maps Key，并严格按照 Google 的指引嵌入到网站源代码中。上个月，你团队的某个开发者为内部原型启用了 Gemini API。现在，你的公共 Maps Key变成了 Gemini 的认证凭证。任何抓取到它的人都可以访问你的上传文件、缓存内容，并让你的 AI 账单飙升。没有人通知你这一变化。

默认配置不安全（Insecure Defaults）。当你在 Google Cloud 创建一个新的 API Key 时，默认状态是“无限制”，意味着它立即对项目中所有已启用的 API（包括 Gemini）有效。UI 会显示“未经授权使用”的警告，但架构上的默认配置本身是完全开放的。

结果：成千上万原本用于计费的无害 API Key，如今成为了公开网络上的 Gemini 凭证。

对独立开发者而言，这恐是一次生存危机

vatcode 便是最新中招的一位开发者。

对大公司来说，vatcode 的经历可能只是一次安全事件。但对独立开发者而言，这是生存问题。

vatcode 的项目严重依赖 Firebase（包括 Firestore、Authentication 等），短时间内几乎不可能迁移。

他已经提交了申诉工单，但 6 天过去，得到的都是“仍在审核中”的模板回复，没有实质进展。

更让他绝望的是，谷歌云将在 4 月 1 日自动从他的银行卡扣款，一旦扣款失败，他的谷歌云账号将被封禁，依托 Firebase 搭建的应用也会直接下线。

“我真的非常害怕，这个设计缺陷会直接毁掉我的生计，以及我这些年的全部努力。”他说。

这不是夸张。对很多小团队来说，一次这样的账单，就足以让项目直接终止。

Reddit 网友热议：谷歌的锅，不该让开发者背

这则帖子很快在 Reddit 引发大量讨论引发了大量开发者共鸣，大家纷纷为这位开发者鸣不平，也吐槽自己的一些遭遇。

网友 GradientAscent713 分享了自己的经历：“我们最早是被安全团队一封‘怒气冲冲’的邮件提醒，才知道这个问题。谷歌通知我们，在公开仓库里发现了我们的某个密钥，还强调保护密钥是用户自己的责任，整封邮件读起来像律师写的。”

他直言，后来才发现，问题根源正是谷歌自身——旧版 Firebase 的客户端密钥，无需任何额外认证就能直接用于 Gemini，“谷歌本该道歉，而不是摆出法律防御姿态，把责任推给客户，这类账单理应由谷歌 100% 承担。”

还有网友直指谷歌预算设置形同虚设：“最糟糕的是，所谓的‘预算’根本不算预算，如果能设置硬性支出上限，达到后自动切断服务，很多悲剧都能避免。”

身为当事人的 vatcode 对此深表认同：“你说到点子上了，现在的‘预算’某种程度上接近虚假宣传，它本质上只是延迟的告警通知。如果能有一个简单的‘达到 50 美元立即封顶、自动关闭服务’的选项，这场噩梦根本不会发生。”

他吐槽，谷歌云要求开发者手动配置复杂的 Pub/Sub 主题、编写自定义 Cloud Functions，才能在告警后程序化关闭计费，这对于独立开发者而言极不合理。

“再加上 30 小时的计费延迟，所谓的预算告警根本不是安全网，更像是一封自动邮件，告诉你：你的创业项目已经完了。”

vatcode 表示，只要谷歌提供一个原生、简单的“硬性封顶”开关，这类问题 99% 都能解决。

开发者该如何避免类似情况的发生？

截至目前，vatcode 还在多渠道找寻解决方案。

而回头看 vatcode、 RatonVaquero 的遭遇之所以频频发生，安全公司 Truffle Security 也曾在报告中指出，这是 Google 对 API key 的“权限提升”，而不是开发者以及 Google 内部的简单“配置错误”。

一切关键都在于这一连串事件的发生顺序：

开发者最初创建了一个 API Key，并将其嵌入网站中用于 Maps 服务。（在那个阶段，这个 Key 是无害的。）

随后，在同一个项目中启用了 Gemini API。（此时，这个 Key 已经可以访问敏感的 Gemini 接口。）

但问题在于，开发者从未收到任何关于权限变化的提示。（这个 Key 在不知不觉中，从一个公开标识，变成了具备敏感权限的凭证。）

Truffle Security 曾扫描发现，互联网上有近 3000 个原本用于谷歌地图的公开 API 密钥，都能直接调用 Gemini API。

面对这种情况，如果你正在使用 Google Cloud（或其相关服务，比如 Maps、Firebase、YouTube 等），该如何有效避免以及自查？

Truffle Security 表示，可以按下面的步骤来排查：

第一步：检查所有 GCP 项目是否启用了 Generative Language API

进入 GCP 控制台，打开「APIs & Services > Enabled APIs & Services」，查找是否存在 “Generative Language API”。

需要对组织下的每一个项目都做一次检查。如果没有启用，那么你就不受这个问题影响。

第二步：如果已启用，逐一审计 API Key

进入「APIs & Services > Credentials」，检查每一个 API Key 的配置，重点关注两类：

带有警告标识的 Key（通常表示“无限制”）

在允许访问的服务列表中，明确包含 Generative Language API 的 Key

这两种情况，都意味着该 Key 可以访问 Gemini。

第三步：确认这些 Key 没有暴露在公网

这是最关键的一步。

如果某个具备 Gemini 权限的 Key 被嵌入在前端 JavaScript、提交到了公开仓库，或者以任何形式暴露在互联网上，那就存在风险。

建议优先检查那些最早创建的 Key——它们很可能是在“API Key 可以公开使用”的旧指导下部署的，后来又在团队某次启用 Gemini API 后，被动获得了新的权限。

一旦发现有暴露的 Key，务必立即进行轮换（重新生成并废弃旧 Key）。

参考：

https://old.reddit.com/r/googlecloud/comments/1s7v5x9/how_googles_insecurebydefault_api_keys_and_a/

https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

本文来自微信公众号“CSDN”，整理：屠敏 ，36氪经授权发布。