想象一下，你三年前在网页里贴了个 Google Maps 的 API Key。
当时官方文档信誓旦旦告诉你：没事，这玩意儿不算秘密，放心贴前端。
结果上周，你的同事在后台手滑开了个 Gemini API。
完蛋，你那个躺在网页源码里吃灰三年的“地图 Key”，瞬间变成了“AI 提款机”。
谁都能拿去调 Gemini，刷爆你的卡，偷走你的私有数据。
最离谱的是，全程没人通知你。
这就是最近 Google Cloud 爆出的“特权升级”漏洞，老实讲，这简直是给所有开发者下了一盘大棋。
曾经的“官方背书”，如今成了催命符
事情得从头说起。
Google Cloud 有个著名的设定：它用同一套 AIza... 格式的 Key，既做公开的项目标识，又做敏感的鉴权凭证。
多年来，Google 一直是这么教开发者的：API Key 不是秘密。
Firebase 的安全清单里白纸黑字写着，Key 可以嵌入客户端代码。Google Maps 的文档也教你直接把 Key 贴进 HTML。
这逻辑本来没毛病。
这些 Key 当初设计就是为了算账，也就是区分是谁在用流量，加上 HTTP Referer 限制，确实不算啥核心机密。
那时候，这是个公开的标识符。
直到 Gemini 横空出世，画风突变。
Gemini 默默改了规则，没人通知你
当你在 Google Cloud 项目里启用 Gemini API 时，一场悄无声息的“越权”就开始了。
以前那个用来显示地图的公开 Key，突然间就获得了访问 Gemini 敏感端点的权限。
没有警告，没有弹窗确认，连封邮件都没有。
这就好比你把家里的备用钥匙放在门口地毯下，原本只能开信箱，结果物业默默换了个锁芯，这把钥匙突然能开你家大门了。
这就是所谓的“追溯性特权扩展”。
你在 2021 年创建了个地图 Key，按规矩贴在网站上。2025 年，团队里有人为了测试开了 Gemini。好家伙，你的公开地图 Key 瞬间变成了 Gemini 凭证。
任何爬到你网页源码的人，都能拿这个 Key 去访问你上传的文件、缓存内容，甚至疯狂刷你的 AI 账单。
更绝的是，Google Cloud 创建新 Key 时，默认是“未限制”状态。这意味着它能访问项目里所有已启用的 API，包括 Gemini。
UI 里虽然有个“未授权使用”的警告，但系统架构默认就是大门敞开的。
结果就是：成千上万个原本人畜无害的计费 Token，现在成了躺在公网上的 Gemini 超级凭证。
连 Google 自己都在裸奔
这事儿有多大？
安全研究人员扫描了 2025 年 11 月的 Common Crawl 数据集，这可是约 700 TiB 的网页存档。
结果发现了 2863 个 活着的、易受攻击的 Google API Key。
受害者名单里不仅有个人开发者，还有大型金融机构、安全公司、全球招聘巨头。
最讽刺的是，连 Google 自己都没幸免。
研究人员发现，Google 某个产品的公开网站上，嵌着一个 2023 年就部署的 Key。原本这 Key 只是用来做个产品展示，结果现在它也能直接访问 Gemini API。
研究人员顺手测了一下 /models 端点，直接返回 200 OK。
你看，连造钥匙的人自己都被锁在门外了，这设计得多“精妙”？
想要赔偿？Google 说这是“预期行为”
更有意思的是披露过程。
去年 11 月 21 日，研究人员把报告交给了 Google。
四天后，Google 回复：这是预期行为。
潜台词就是：“我们就是这么设计的，不关我们事。”
研究人员没放弃，反手甩过去 Google 自己产品中招的证据。这下 Google 内部坐不住了。
12 月 2 日，Google 态度大转弯，把报告从“客户问题”改成了“Bug”，并提升了严重等级。
虽然 Google 承诺修复，比如限制新 Key 的默认权限，封锁被泄露的 Key，但说实话，这有点亡羊补牢。
评论区里早就炸锅了。有人提到，Google AI Studio 甚至鼓励部署带 Key 的应用，导致很多不明真相的开发者把每个月几万美元的额度直接暴露在公网。
还有人吐槽：既然 Key 不是秘密，那哪来的“泄露”一说？如果真的要修，为什么不直接禁止旧 Key 访问 Gemini？
这逻辑，确实有点绕。
别等账单爆了才后悔
我个人觉得，这事儿与其说是漏洞，不如说是技术债的大爆发。
在 AI 时代，旧的权限模型正在崩塌。原本安全的“公开标识符”，在新功能加持下，随时可能变成致命的“敏感凭证”。
如果你手头有 Google Cloud 项目，现在立刻马上去做三件事：
第一，去 GCP 控制台，看看有没有启用 “Generative Language API”。 如果没开，恭喜你，暂时安全。
第二，如果开了，赶紧去“凭据”页面审计 API Key。 尤其是那些带黄色警告图标的“无限制” Key，或者明确写了能访问 Gemini 的 Key。
第三，检查你的前端代码。 确认那些 Key 没有被嵌入 JavaScript 或者提交到公开仓库。特别是那些上了年头的老项目，最容易被新功能“背刺”。
毕竟，连 Google 自己都差点栽进去，你确定你比 Google 的工程师更细心？
在这个 AI 狂奔的年代，你以为的“安全默认值”，可能早就过时了。
参考链接：
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules