谷歌长期以来向开发者明确表示，Google API密钥（如用于地图、Firebase等服务的密钥）并非敏感信息，可以安全地嵌入前端代码中。然而，随着Gemini API的推出，这一规则被悄然打破：原本仅用于公共标识和计费的API密钥，如今也能直接用于访问敏感的Gemini服务，包括读取用户上传文件、缓存数据，甚至盗用账户额度进行大模型调用。 安全公司Truffle Security的调查发现，仅在2025年11月的Common Crawl数据集中，就发现了2863个公开暴露的Google API密钥，这些密钥最初用于Google Maps等公共服务，但因项目中启用了Gemini API，已具备访问敏感AI接口的权限。攻击者只需从网页源码中提取密钥，即可通过API调用获取响应，无需额外认证。 问题核心在于Google Cloud采用统一的AIza...格式密钥，同时服务于两种截然不同的用途：一是公开的项目标识（用于计费和限制），二是敏感的身份认证（用于AI服务）。过去，开发者被允许将密钥嵌入前端，因为它们本就不具备认证能力。但Gemini上线后，只要在项目中启用该API，所有现有密钥——无论是否公开——都会被自动赋予对Gemini的访问权限，且无任何警告或确认提示。 这导致两大风险：一是“回溯式权限提升”——一个三年前公开部署的Maps密钥，因团队启用Gemini而突然变成可访问私有数据的凭证；二是“不安全默认配置”——新生成的密钥默认为“无限制”，可访问项目中所有启用的API，包括Gemini。 更令人震惊的是，调查人员成功使用谷歌自身产品网站上公开部署的旧密钥，访问了谷歌内部的Gemini服务，证明连谷歌自己也未能幸免。 该漏洞被报告给谷歌后，起初被判定为“设计使然”，但在提供谷歌自身密钥的证据后，谷歌于12月2日将其升级为“Bug”并启动修复。目前，谷歌已建立检测机制，主动封禁暴露密钥，并承诺修复根本问题。 作为开发者，应立即采取行动：检查所有GCP项目是否启用了“生成式语言API”；审计每个API密钥的权限范围，确认是否有Gemini访问权限；特别关注那些嵌入前端或公开在代码库中的旧密钥。一旦发现暴露密钥，立即更换。推荐使用TruffleHog等工具扫描代码和网页资产，识别并验证活跃的高危密钥。 这一事件揭示了一个深层问题：当AI能力被快速叠加到旧有系统架构上，遗留的“非秘密”密钥可能在不知不觉中变成“致命密钥”。未来，企业需重新审视API密钥管理策略，避免因默认配置不当而引发大规模安全风险。