Google 花了十多年告诉开发者：API Key 不是秘密，可以放心写在前端代码里。但现在这个说法不再成立了。因为 Gemini。
发生了什么
安全公司 Truffle Security 最近发现了一个严重问题：他们扫描了数百万个网站，找到了近 3000 个暴露在公网上的 Google API Key，这些 Key 原本是用于 Google Maps、Firebase 等公开服务的，但现在它们同时也能访问 Gemini API。
这意味着什么？攻击者可以：
- 访问你上传到 Gemini 的私有文件和缓存数据
- 用你的账号跑 LLM 请求，账单算你的
- 耗尽你的配额，让你的服务挂掉
更讽刺的是，连 Google 自己的 API Key 也中招了。研究者用 Google 产品网站上公开的 Key 成功访问了 Google 内部的 Gemini。
问题的根源
Google Cloud 用同一种格式的 API Key 做两件完全不同的事：
- 公开标识 - 比如 Google Maps，Key 只是用来计费和识别项目，本身不敏感
- 敏感认证 - 比如 Gemini，Key 可以访问私有数据
以前这没问题。Google 的官方文档明确说 API Key 可以写在前端 JavaScript 里，Firebase 的安全清单也说 API Key 不是秘密。
然后 Gemini 来了。
当你在一个 GCP 项目里启用 Gemini API 时，这个项目里所有现有的 API Key 都会自动获得访问 Gemini 的权限。没有警告，没有确认弹窗，没有邮件通知。
一个典型的中招场景
- 三年前，你创建了一个 API Key 用于网站的 Google Maps 嵌入，按照官方文档写在了 HTML 里
- 上个月，团队里有人为了内部原型启用了 Gemini API
- 你那个公开的 Maps Key 现在变成了 Gemini 凭证
- 任何人都可以从你网站的源码里复制这个 Key，然后访问你的 Gemini 数据
没人告诉你这件事发生了。
Google 的回应
Truffle Security 在 2025 年 11 月报告了这个问题。一开始 Google 说这是预期行为，但在研究者提供了 Google 自己基础设施的例子后，Google 重新分类为 Bug。
Google 承诺的修复措施：
- 新 Key 默认限制 - 通过 AI Studio 创建的新 Key 将默认只能访问 Gemini
- 泄露 Key 封禁 - 检测到泄露的 Key 会被自动封禁
- 主动通知 - 发现泄露 Key 时会通知用户
但目前根本性的修复还没完成。
你现在应该做什么
1. 检查你的 GCP 项目
去 GCP 控制台，检查每个项目是否启用了 Generative Language API（就是 Gemini API）。如果没启用，你暂时安全。
2. 审计你的 API Key
如果启用了 Gemini API，去 APIs and Services 的 Credentials 检查每个 Key：
- 有警告图标的（unrestricted）= 危险
- 明确列出 Generative Language API 的 = 危险
3. 检查这些 Key 是否公开
如果一个能访问 Gemini 的 Key 出现在前端 JavaScript、公开的 Git 仓库、或任何公网可访问的地方，立即轮换这个 Key。
我的看法
这个问题的本质是向后兼容性和安全性的冲突。Google 为了让 Gemini 快速集成到现有生态，选择复用了现有的 API Key 体系。这在产品角度是合理的，但从安全角度，这是一个典型的权限静默升级问题。
更深层的问题是：Google 用同一种 Key 格式做公开标识和敏感认证。这在设计上就是有问题的。像 Stripe 那样区分 Publishable Key 和 Secret Key 才是正确的做法。
如果你在用 GCP，现在就去检查一下你的 API Key 吧。
原文：Google API Keys Weren't Secrets. But then Gemini Changed the Rules.