文章总结： 文章揭示GoogleAPI密钥安全隐患，原本作为公开标识符的密钥在启用GeminiAPI后自动获得敏感权限，导致暴露在前端代码中的密钥变成有效Gemini凭据。攻击者可借此访问私有数据、滥用账单或实施拒绝服务。安全团队发现2863个活跃密钥存在此问题，建议用户立即检查GCP项目是否启用GenerativeLanguageAPI，排查未受限密钥并及时轮换。 综合评分： 88 文章分类： 漏洞预警,云安全,数据安全,应用安全,安全建设

你网站上的 Google Maps 密钥，现在能直接访问 Gemini

原创

SecureNexusLab SecureNexusLab

SecureNexusLab

2026年2月26日 17:59 北京

十多年来，Google 一直告诉开发者：API 密钥不算秘密，可以放心嵌入前端代码。但 Gemini 的出现彻底改变了这个假设，AIza... 密钥如今能访问用户的私有数据。安全研究人员扫描了数百万个网站，找到了近 3,000 个暴露在公共互联网上的 Google API 密钥，原本只是 Maps 或 Firebase 的计费令牌，现在却成了 Gemini 的有效凭据。

API 密钥本来不是秘密

Google Cloud 的 API 密钥（前缀 AIza...）在设计之初是一个项目标识符，用于将 API 调用关联到 GCP 项目以进行计费和配额管理。谷歌云的凭据通常分三个层级：API 密钥、OAuth 2.0 令牌、服务账户密钥。API 密钥属于最低级别——就算泄露，攻击者最多薅一些配额，拿不到敏感数据。

正因如此，Google 长期建议开发者将 API 密钥嵌入客户端代码，Firebase 安全文档也白纸黑字写着”API 密钥不是秘密”。放在当时，这套逻辑没什么问题。

Gemini 打破了安全假设

问题的根源在于：Google 用同一种密钥格式干了两件完全不同的事——公开标识和敏感身份验证。

当你在某个 GCP 项目上启用 Gemini API后，该项目中所有未受限制的 API 密钥都会自动获得访问 Gemini 端点的权限。没有弹窗提示，没有确认对话框，也没有邮件通知。GCP 中未做限制的 API 密钥默认对项目里所有已启用 API 生效，每启用一个新服务，密钥就自动多一份权限。

这意味着你三年前创建了一个 Maps 密钥，按文档指引写进网站源码。上个月团队里有人启用了 Gemini API，你那个公开的密钥就悄然变成了 Gemini 凭据。此外，GCP 控制台中新建密钥的默认状态就是”不受限制”，虽然 UI 上会显示警告，但底层行为是完全开放的。

结果：数以千计原本作为计费令牌部署的 API 密钥，变成了暴露在公共互联网上的活跃 Gemini 凭据。

权限提升，而非配置错误

这不是用户的配置问题，而是平台层面的设计缺陷。关键在于时间线：开发者先创建密钥嵌入网站用于 Maps（此时密钥无害）→ 同一项目启用 Gemini API（密钥自动获得敏感权限）→ 开发者从未被告知权限变化。密钥从公共标识符变成了秘密凭据，而持有者对此一无所知。

虽然用户可以手动限制密钥的作用范围，但平台的默认行为构成了两个经典安全缺陷：不安全的默认配置（CWE-1188）和不当的权限管理（CWE-269）。作为对比，Stripe 的设计就清晰得多——pk_live_ 是公开密钥，sk_live_ 是私密密钥，两者泾渭分明。Google 用同一种密钥格式覆盖公开和私密场景，混乱几乎是必然的。

攻击路径与影响

攻击者访问你的网站，从页面源码中复制 AIza... 密钥，然后执行：

curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"

返回的不是 403 Forbidden，而是 200 OK。从这里开始，攻击者可以：访问私有数据——Gemini API 的 /files/ 和 /cachedContents/ 端点可能包含上传的数据集、内部文档和缓存上下文；账单滥用——Gemini 按 Token 计费，使用 Gemini 1.5 Pro 的百万 Token 上下文窗口，单次请求成本可达数美元，大量调用可能每天产生数千美元费用；拒绝服务——恶意调用耗尽配额，导致合法服务中断。

整个攻击链零交互、零漏洞利用，仅依赖一个设计缺陷。

应对与自查

Truffle 公司大规模扫描发现了 2,863 个活跃密钥后，Google 已开始采取改进措施：通过 AI Studio 创建的新密钥将默认仅限 Gemini 访问；泄露密钥将被默认拦截；计划主动通知受影响的项目所有者。

如果你使用 Google Cloud 相关服务，建议立即自查：首先在 GCP 控制台的 APIs & Services 中确认 Generative Language API 是否已启用；然后在 Credentials 页面检查每个 API 密钥是否为”Unrestricted”或是否在允许列表中包含 Generative Language API——两种情况都意味着密钥能访问 Gemini；重点排查最老的密钥，这些密钥最可能在”API 密钥可以安全公开”的旧指南下被嵌入前端代码；发现已暴露的密钥应立即轮换。

遗留凭据的攻击面

公共标识符悄然获得敏感权限，这种模式并非 Google 独有。随着越来越多的组织将 AI 能力嫁接到现有平台上，遗留凭据的攻击面正在以意想不到的方式扩大。不过这种手法并没有想象中的那么普遍，数百万个网站只有三千个可被利用的密钥，而且只能说思路上的启迪大于攻击手法本身。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：SecureNexusLab SecureNexusLab SecureNexusLab《你网站上的 Google Maps 密钥，现在能直接访问 Gemini》