整理 | 屠敏出品 | CSDNIDCSDNnews一次看似普通的测试操作却引来 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-checklistvatcode 也一直按这个理解在使用认为这类密钥安全无虞。转折点发生在几天前为了给自己的应用添加一个 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推荐阅读OpenClaw 从翻车到迎来上百项更新MiniMax、腾讯、阿里、有道 8 位专家拆解OpenClaw本土化实战解法1.9万行Claude Code代码引发百人联名“封杀”Node.js核心成员请愿项目里应禁止AI辅助开发月下载1.3亿的库被AI重写并改了协议开源维护者遭“网暴”后发声我觉得大家反应有点过头当时联系不到原作者新版是重写【活动分享】48 小时与 50 位大厂技术决策者共探 AI 落地真路径。由 CSDN奇点智能研究院联合举办的「全球机器学习技术大会」正式升级为「奇点智能技术大会」。2026 奇点智能技术大会将于 4 月 17-18 日在上海环球港凯悦酒店正式召开大会聚焦大模型技术演进、智能体系统工程、OpenClaw 生态实践及 AI 行业落地等十二大专题板块特邀来自BAT、京东、微软、小红书、美团等头部企业的 50 位技术决策者分享实战案例。旨在帮助技术管理者与一线 AI 落地人员规避选型风险、降低试错成本、获取可复用的工程方法论真正实现 AI 技术的规模化落地与商业价值转化。这不仅是一场技术的盛宴更是决策者把握 2026 AI 拐点的战略机会。