Google API密钥也能访问Gemini私人数据？2026年安全风险实测

Google API 密钥：从公开标识符到 Gemini 凭证的安全分析

tl;dr Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data. We scanned millions of websites and found nearly 3,000 Google API keys, originally deployed for public services like Google Maps, that now also authenticate to Gemini even though they were never intended for it. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account. Even Google themselves had old public API keys, which they thought were non-sensitive, that we could use to access Google’s internal Gemini.

长话短说：谷歌过去十多年一直告诉开发者，Google API 密钥（如用于 Maps、Firebase 等的密钥）并非机密。但如今情况变了：Gemini 接受同样的密钥来访问你的私人数据。我们扫描了数百万个网站，发现近 3,000 个原本用于 Google Maps 等公开服务的 Google API 密钥，现在也能用于 Gemini 的身份验证，尽管它们从未被设计用于此。攻击者只需获得一个有效密钥，就能访问上传的文件、缓存数据，并将大模型使用费用记在你的账户上。就连谷歌自身也曾拥有我们能够用来访问其内部 Gemini 的旧公开 API 密钥（他们原以为这些密钥不敏感）。

The Core Problem

核心问题

Google Cloud uses a single API key format (AIza...) for two fundamentally different purposes: public identification and sensitive authentication.

Google Cloud 使用同一种 API 密钥格式（AIza...）服务于两种截然不同的目的：公开标识和敏感认证。

For years, Google has explicitly told developers that API keys are safe to embed in client-side code. Firebase's own security checklist states that API keys are not secrets.

多年来，谷歌明确告诉开发者，将 API 密钥嵌入客户端代码是安全的。Firebase 的安全检查清单甚至写明 API 密钥不是机密。

Note: these are distinctly different from Service Account JSON keys used to power GCP.

注意：这些密钥与用于 GCP 的服务账户 JSON 密钥有显著区别。

Source: Firebase Security Checklist

来源：Firebase 安全检查清单

Google's Maps JavaScript documentation instructs developers to paste their key directly into HTML.

Google 的 Maps JavaScript 文档指示开发者直接将密钥粘贴到 HTML 中。

Source: Google Maps JavaScript API Key Guide

来源：Google Maps JavaScript API 密钥指南

This makes sense. These keys were designed as project identifiers for billing, and can be further restricted with (bypassable) controls like HTTP referer allow-listing. They were not designed as authentication credentials.

这合乎逻辑。这些密钥被设计为用于计费的项目标识符，并可通过 HTTP referer 白名单等（可绕过的）控制措施进一步限制。它们并非作为身份验证凭证而设计。

Then Gemini arrived.

然后 Gemini 来了。

When you enable the Gemini API (Generative Language API) on a Google Cloud project, existing API keys in that project (including the ones sitting in public JavaScript on your website) can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification.

当你在 Google Cloud 项目中启用 Gemini API（Generative Language API）时，该项目中现有的 API 密钥（包括那些放在你网站公开 JavaScript 中的密钥）可以静默地获得对敏感 Gemini 端点的访问权限。没有警告，没有确认对话框，也没有电子邮件通知。

This creates two distinct problems:

这造成了两个截然不同的问题：

• Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you.

• 追溯性权限提升。你三年前按照谷歌的指示创建了一个 Maps 密钥并嵌入到网站源代码中。上个月，团队中的一名开发者为内部原型启用了 Gemini API。你公开的 Maps 密钥现在变成了 Gemini 凭证。任何人只要能抓取到它，就能访问你上传的文件、缓存内容，并产生高昂的 AI 费用。没有人通知你。

• Insecure Defaults. When you create a new API key in Google Cloud, it defaults to "Unrestricted," meaning it's immediately valid for every enabled API in the project, including Gemini. The UI shows a warning about "unauthorized use," but the architectural default is wide open.

• 不安全的默认设置。当你在 Google Cloud 中创建新的 API 密钥时，默认设置为“无限制”，这意味着该密钥立即对项目中所有已启用的 API（包括 Gemini）有效。界面上虽然会显示“未经授权使用”的警告，但架构上的默认设置是完全开放的。

The result: thousands of API keys that were deployed as benign billing tokens are now live Gemini credentials sitting on the public internet.

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

What makes this a privilege escalation rather than a misconfiguration is the sequence of events.

这是一个权限提升问题，而非配置错误，关键在于事件的先后顺序。

1. A developer creates an API key and embeds it in a website for Maps. (At that point, the key is harmless.)
   开发者创建了一个 API 密钥，并将其嵌入到网站的 Maps 中。（此时该密钥无害。）
2. The Gemini API gets enabled on the same project. (Now that same key can access sensitive Gemini endpoints.)
   同一个项目中启用了 Gemini API。（现在同一个密钥可以访问敏感的 Gemini 端点。）
3. The developer is never warned that the key's privileges changed underneath it. (The key went from public identifier to secret credential).
   开发者从未被告知密钥的权限在底层发生了变更。（密钥从公开标识符变成了秘密凭证。）

While users can restrict Google API keys (by API service and application), the vulnerability lies in the Insecure Default posture (CWE-1188) and Incorrect Privilege Assignment (CWE-269):

虽然用户可以限制 Google API 密钥（按 API 服务和应用程序），但漏洞根源在于不安全的默认设置（CWE-1188）和不正确的权限分配（CWE-269）：

• Implicit Trust Upgrade: Google retroactively applied sensitive privileges to existing keys that were already rightfully deployed in public environments (e.g., JavaScript bundles).
• 隐式信任升级：谷歌追溯性地将敏感权限应用于已在公开环境中合法部署的现有密钥（例如 JavaScript 包）。
• Lack of Key Separation: Secure API design requires distinct keys for each environment (Publishable vs. Secret Keys). By relying on a single key format for both, the system invites compromise and confusion.
• 缺乏密钥分离：安全的 API 设计要求为不同环境使用不同的密钥（可发布密钥 vs 秘密密钥）。依赖同一种密钥格式同时用于两种用途，必然导致安全风险和混乱。

Failure of Safe Defaults: The default state of a generated key via the GCP API panel permits access to the sensitive Gemini API (assuming it’s enabled). A user creating a key for a map widget is unknowingly generating a credential capable of administrative actions.

安全默认值失效：通过 GCP API 面板生成的密钥默认状态下允许访问敏感的 Gemini API（假设已启用）。用户为地图小组件创建密钥时，不知不觉中生成了一个可执行管理操作凭证。

What an Attacker Can Do

攻击者能够做什么

The attack is trivial. An attacker visits your website, views the page source, and copies your AIza... key from the Maps embed. Then they run:

攻击非常简单。攻击者访问你的网站，查看页面源代码，从 Maps 嵌入代码中复制你的 AIza... 密钥，然后执行：

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

Instead of a 403 Forbidden, they get a 200 OK. From here, the attacker can:

他们得到的不是 403 Forbidden，而是 200 OK。此时攻击者可以：

• Access private data. The /files/ and /cachedContents/ endpoints can contain uploaded datasets, documents, and cached context. Anything the project owner stored through the Gemini API is accessible.
• 访问私有数据。/files/ 和 /cachedContents/ 端点可能包含上传的数据集、文档和缓存上下文。项目所有者通过 Gemini API 存储的任何内容都可以被访问。
• Run up your bill. Gemini API usage isn't free. Depending on the model and context window, a threat actor maxing out API calls could generate thousands of dollars in charges per day on a single victim account.
• 增加你的账单。Gemini API 使用不是免费的。根据模型和上下文窗口的不同，攻击者最大化 API 调用量后，单个受害账户每天可能产生数千美元的费用。
• Exhaust your quotas. This could shut down your legitimate Gemini services entirely.
• 耗尽你的配额。这可能导致你的合法 Gemini 服务完全瘫痪。

The attacker never touches your infrastructure. They just scrape a key from a public webpage.

攻击者从不接触你的基础设施，只需从公共网页抓取一个密钥即可。

2,863 Live Keys on the Public Internet

公共互联网上的 2,863 个活跃密钥

To understand the scale of this issue, we scanned the November 2025 Common Crawl dataset, a massive (~700 TiB) archive of publicly scraped webpages containing HTML, JavaScript, and CSS from across the internet. We identified 2,863 live Google API keys vulnerable to this privilege-escalation vector.

为了了解问题的规模，我们扫描了 2025 年 11 月的 Common Crawl 数据集——一个包含来自互联网各地的 HTML、JavaScript 和 CSS 的庞大数据集（约 700 TiB）。我们识别出 2,863 个活跃的 Google API 密钥，容易受到这种权限提升攻击。

Example Google API key in front-end source code used for Google Maps, but also can access Gemini

前端源代码中用于 Google Maps 的 Google API 密钥示例，但它也可以访问 Gemini

These aren't just hobbyist side projects. The victims included major financial institutions, security companies, global recruiting firms, and, notably, Google itself. If the vendor's own engineering teams can't avoid this trap, expecting every developer to navigate it correctly is unrealistic.

这些并非只是业余爱好者的副项目。受害者包括大型金融机构、安全公司、全球招聘公司，以及值得注意的是，谷歌本身。如果供应商自己的工程团队都无法避开这个陷阱，那么期望每个开发者都能正确处理是不现实的。

Proof of Concept: Google's Own Keys

概念验证：谷歌自己的密钥

We provided Google with concrete examples from their own infrastructure to demonstrate the issue. One of the keys we tested was embedded in the page source of a Google product's public-facing website. By checking the Internet Archive, we confirmed this key had been publicly deployed since at least February 2023, well before the Gemini API existed. There was no client-side logic on the page attempting to access any Gen AI endpoints. It was used solely as a public project identifier, which is standard for Google services.

我们向谷歌提供了来自其自身基础设施的具体示例以证明问题。我们测试的一个密钥嵌入在谷歌某产品面向公众网站的页面源代码中。通过检查 Internet Archive，我们确认该密钥自 2023 年 2 月起就已公开部署，远在 Gemini API 出现之前。页面上没有任何客户端逻辑试图访问任何生成式 AI 端点，它仅被用作公开的项目标识符——这对谷歌服务来说是标准做法。

We tested the key by hitting the Gemini API's /models endpoint (which Google confirmed was in-scope) and got a 200 OK response listing available models. A key that was deployed years ago for a completely benign purpose had silently gained full access to a sensitive API without any developer intervention.

我们通过向 Gemini API 的 /models 端点（谷歌确认该端点属于测试范围）发送请求来测试该密钥，得到了 200 OK 响应，列出了可用模型。一个多年前为完全良性的目的而部署的密钥，在没有开发者任何干预的情况下，静默地获得了对敏感 API 的完全访问权限。

The Disclosure Timeline

披露时间线

Credit Where It's Due

应得的肯定

Transparently, the initial triage was frustrating; the report was dismissed as "Intended Behavior”. But after providing concrete evidence from Google's own infrastructure, the GCP VDP team took the issue seriously.

坦率地说，最初的分类令人沮丧；报告被当作"预期行为"驳回。但在提供了来自谷歌自身基础设施的具体证据后，GCP VDP 团队认真对待了这个问题。

They expanded their leaked-credential detection pipeline to cover the keys we reported, thereby proactively protecting real Google customers from threat actors exploiting their Gemini API keys. They also committed to fixing the root cause, though we haven't seen a concrete outcome yet.

他们扩展了泄露凭证检测管道，以覆盖我们报告的密钥，从而主动保护真实的谷歌客户免受利用其 Gemini API 密钥的攻击者侵害。他们还承诺修复根本原因，尽管我们尚未看到具体成果。

Building software at Google's scale is extraordinarily difficult, and the Gemini API inherited a key management architecture built for a different era. Google recognized the problem we reported and took meaningful steps. The open questions are whether Google will inform customers of the security risks associated with their existing keys and whether Gemini will eventually adopt a different authentication architecture.

在谷歌的规模上构建软件极其困难，Gemini API 继承了为不同时代构建的密钥管理架构。谷歌认可了我们报告的问题并采取了有意义的措施。悬而未决的问题是：谷歌是否会通知客户其现有密钥相关的安全风险，以及 Gemini 最终是否会采用不同的身份验证架构。

Where Google Says They're Headed

谷歌表示他们未来的方向

Google publicly documented its roadmap. This is what it says:

谷歌公开记录了其路线图，内容如下：

• Scoped defaults. New keys created through AI Studio will default to Gemini-only access, preventing unintended cross-service usage.
• 限定范围的默认值。通过 AI Studio 创建的新密钥默认将仅限 Gemini 访问，防止意外的跨服务使用。
• Leaked key blocking. They are defaulting to blocking API keys that are discovered as leaked and used with the Gemini API.
• 阻止泄露密钥。他们默认会阻止被发现已泄露并被用于 Gemini API 的密钥。
• Proactive notification. They plan to communicate proactively when they identify leaked keys, prompting immediate action.
• 主动通知。他们计划在识别到泄露密钥时主动通知，提示立即采取行动。

These are meaningful improvements, and some are clearly already underway. We'd love to see Google go further and retroactively audit existing impacted keys and notify project owners who may be unknowingly exposed, but honestly, that is a monumental task.

这些都是有意义的改进，有些显然已经在进行中。我们很希望看到谷歌更进一步，对现有受影响的密钥进行追溯审计，并通知可能无意中暴露的项目所有者，但老实说，这是一项艰巨的任务。

What You Should Do Right Now

你现在应该做什么

If you use Google Cloud (or any of its services like Maps, Firebase, YouTube, etc), the first thing to do is figure out whether you're exposed. Here's how.

如果你使用 Google Cloud（或其任何服务，如 Maps、Firebase、YouTube 等），首先要做的是确定你是否暴露。具体方法如下：

Step 1: Check every GCP project for the Generative Language API.
第一步：检查每个 GCP 项目是否启用了 Generative Language API。

Go to the GCP console, navigate to APIs & Services > Enabled APIs & Services, and look for the "Generative Language API." Do this for every project in your organization. If it's not enabled, you're not affected by this specific issue.

前往 GCP 控制台，导航至 API 和服务 > 已启用的 API 和服务，查找"Generative Language API"。对你组织中的每个项目执行此操作。如果未启用，则你不会受到此特定问题的影响。

Step 2: If the Generative Language API is enabled, audit your API keys.
第二步：如果 Generative Language API 已启用，请审计你的 API 密钥。

Navigate to APIs & Services > Credentials. Check each API key's configuration. You're looking for two types of keys:

导航至 API 和服务 > 凭据。检查每个 API 密钥的配置。需要关注两种类型的密钥：

• Keys that have a warning icon, meaning they are set to unrestricted
• 带有警告图标的密钥，表示设置为无限制
• Keys that explicitly list the Generative Language API in their allowed services
• 在其允许的服务中明确列出 Generative Language API 的密钥

Either configuration allows the key to access Gemini.

这两种配置都允许该密钥访问 Gemini。

Act now: If you find any unrestricted keys or keys that include Gemini, restrict them immediately. Create separate, dedicated keys for each service—one for Maps, one for Gemini, and so on. Ensure that public-facing keys (e.g., in JavaScript) are restricted to the specific API they need, and never allow them to access sensitive endpoints like Gemini.

立即行动：如果你发现任何无限制的密钥或包含 Gemini 的密钥，请立即限制它们。为每个服务创建独立的专用密钥——一个用于 Maps，一个用于 Gemini，以此类推。确保面向公众的密钥（如 JavaScript 中的密钥）仅限于它们所需的特定 API，绝不允许它们访问 Gemini 等敏感端点。

This issue highlights a fundamental security design flaw in Google's API key system. While Google has taken steps to mitigate future risks, the existing keys on the internet remain a serious threat. Until Google fully addresses the root cause, every developer must treat their API keys as potential credentials, not just identifiers.

这个问题凸显了 Google API 密钥系统的基本安全设计缺陷。虽然谷歌已采取措施缓解未来风险，但互联网上现有的密钥仍然是一个严重威胁。在谷歌完全解决根本原因之前，每个开发者都必须将其 API 密钥视为潜在凭证，而不仅仅是标识符。

Stay vigilant, restrict your keys, and check your projects today.

保持警惕，限制你的密钥，立即检查你的项目。

常见问题（FAQ）

为什么Google API密钥从非机密变成了Gemini凭证？

启用Gemini API后，项目中所有现有API密钥自动获得访问Gemini敏感端点的权限，尽管它们原本仅用于公开服务如Maps，导致密钥变为敏感凭证。

Google Maps API密钥被用于Gemini会有什么风险？

攻击者可用该密钥访问上传文件、缓存数据，并向你的账户收取LLM使用费用，造成数据泄露和财务损失。

如何防止我的API密钥被滥用访问Gemini？

限制密钥使用范围，只允许指定服务；禁用不需要的Gemini API；为不同用途创建独立密钥，并定期轮换。