Google Said API Keys Aren't Secrets
For more than a decade, Google told developers that API keys are not credentials. The Firebase security checklist says it plainly: "API keys for Firebase services are not secret." The Maps JavaScript API documentation instructs developers to paste their key directly into HTML script tags. Google Cloud documentation reinforces this message across dozens of product pages.
This guidance made sense at the time. Google API keys were project identifiers used for billing and quota tracking. They were not authentication credentials. They did not grant access to private data. They did not authorize write operations. A key embedded in your website's source code could be used by anyone to make Maps API calls, but all that would do is run up your bill. Google offered HTTP referrer restrictions and API restrictions as optional safeguards, but the core message was clear: these keys are safe to expose.
Developers followed these instructions. Frontend developers embedded Maps keys in HTML. Mobile developers shipped Firebase keys in public app bundles. DevOps engineers committed keys to public repositories. Infrastructure-as-code templates hardcoded them. Google's own documentation examples showed keys in plain text. This was considered correct practice per the vendor's own guidance.
The Firebase docs even address the concern directly, telling developers that including API keys in code or config files is "not a security risk." For years, that statement was accurate. Then Google shipped Gemini.
Then Gemini Changed the Rules
When you enable the Generative Language API (the backend for Gemini) on a Google Cloud Platform project, something happens that no one warns you about. Every existing API key in that project silently gains access to sensitive Gemini endpoints. No warning dialog. No confirmation prompt. No email notification. No audit log entry that would catch an administrator's attention.
The three-year-old Maps key sitting in your website's page source is now a Gemini credential. The Firebase key hardcoded into your mobile app is now a Gemini credential. The key in that public GitHub repository your intern committed two years ago is now a Gemini credential.
Two distinct failures created this situation:
- Retroactive privilege expansion
- Enabling the Gemini API on a project retroactively grants Gemini access to every existing unrestricted key. Keys that were deployed months or years earlier under the assumption that they were low-risk project identifiers suddenly became high-risk authentication tokens. The key's permissions changed after deployment without the key holder's knowledge or consent.
- Insecure defaults
- New API keys in Google Cloud default to "Unrestricted," meaning they can access every enabled API in the project. When a developer creates a key for Maps and does not explicitly restrict it, that key can also access Gemini, Cloud Storage, BigQuery and every other enabled API. Google's own API key best practices recommend restrictions, but the default configuration grants maximum access.
This is privilege escalation, not misconfiguration. The developers who deployed these keys followed Google's documentation. They did not make a mistake. The platform changed the security properties of their deployed credentials without notice.
What an Attacker Can Do
The attack is trivial. An attacker views the page source of any website using Google Maps, copies the AIza key from the script tag and tests it against the Gemini API. The entire process takes less than thirty seconds.
A single curl command confirms whether the key has Gemini access:
| Endpoint | What It Returns |
|---|---|
/v1beta/files?key=$API_KEY |
Lists all files uploaded to the project's Gemini instance, including private datasets and documents |
/v1beta/cachedContents?key=$API_KEY |
Returns cached content from previous Gemini sessions, potentially containing proprietary data |
/v1beta/models/gemini-pro:generateContent?key=$API_KEY |
Generates content using the project's Gemini quota and billing |
If the /v1beta/files endpoint returns HTTP 200, the key is live. The attacker now has read access to every file uploaded through the Gemini API for that project. This includes training datasets, uploaded documents, proprietary research and any other content developers fed into Gemini during development or production use.
Beyond data access, the attacker can generate Gemini API calls against the victim's billing account. Gemini Pro and Ultra models are expensive at scale. An attacker running automated queries can accumulate thousands of dollars in charges per day. They can also exhaust the project's quotas, effectively performing a denial-of-service against the victim's legitimate Gemini usage.
The critical detail: the attacker never touches the victim's infrastructure. No firewall logs. No server access logs. No IDS alerts. The API calls go directly to Google's servers using a legitimately issued key. From Google's perspective, these are authorized requests.
2,863 Live Keys on the Public Internet
Security researchers scanned the November 2025 Common Crawl dataset, a public archive of approximately 700 TiB of web content. They extracted every string matching the AIza key format and tested each one against the Gemini API's files endpoint.
The results were significant: 2,863 live Google API keys responded with HTTP 200 to the Gemini files endpoint. These keys were embedded in the HTML source of public websites across every industry sector.
Victims included major financial institutions with Maps embeds on branch locator pages. Security companies had vulnerable keys on their own product websites. Global recruiting firms exposed keys through embedded Google Maps on office location pages. Healthcare organizations, universities and government contractors all appeared in the results.
The most notable finding: Google's own engineering teams had vulnerable keys deployed on public-facing product websites. One Google key had been publicly deployed since February 2023, which predates the general availability of the Gemini API. That key was deployed correctly per Google's own documentation at the time. The Gemini API was enabled on the project later, retroactively turning a harmless Maps key into a Gemini credential without anyone at Google noticing.
The researchers responsibly disclosed the full list of affected keys to Google rather than publishing them. But the Common Crawl dataset is public. Anyone with the technical skill to write a regex and a curl loop could replicate this scan today.
The CWE Classification
This vulnerability maps to two established weakness classifications in the MITRE Common Weakness Enumeration:
- CWE-1188: Insecure Default Initialization of Resource
- New API keys default to unrestricted access across all enabled APIs. When the Gemini API is enabled on a project, keys that were never intended for AI access inherit it by default. The secure configuration requires explicit action by the developer. The insecure configuration is what ships out of the box.
- CWE-269: Improper Privilege Management
- Enabling a new API on a project retroactively expands the privileges of all existing keys. Privilege changes propagate without notification. There is no mechanism for key holders to consent to or even be informed of the expanded access.
It is important to be precise about what happened here. This is not a case of developers forgetting to restrict their keys. The keys were deployed correctly per Google's published guidance. Google's documentation told them the keys were safe to expose. The platform then changed the security properties of those keys without notification. The fault lies in the platform's default behavior, not in the developers who followed the vendor's instructions.
The Disclosure Timeline
- November 21, 2025
- Researchers reported the vulnerability to Google's Vulnerability Disclosure Program (VDP) with full technical details and a sample of affected keys.
- November 25, 2025
- Google initially dismissed the report, classifying it as "intended behavior" and stating that API key restriction is the developer's responsibility.
- December 1, 2025
- Researchers escalated by providing examples of vulnerable keys from Google's own infrastructure, demonstrating that even Google's internal teams were affected by the insecure defaults.
- December 2, 2025
- Google reclassified the report as a confirmed bug. Severity was upgraded. Google's security team requested the full list of 2,863 affected keys for remediation.
- December 12, 2025
- Google shared a remediation plan with the researchers, outlining planned changes to default key behavior and leaked key detection.
- January 13, 2026
- Google classified the issue as "Single-Service Privilege Escalation, READ" at Tier 1 severity under their internal vulnerability taxonomy.
- February 19, 2026
- The 90-day responsible disclosure window expired. Researchers published their findings.
The initial dismissal as "intended behavior" is worth noting. Google's first response was that developers should restrict their keys. This framing ignores that Google's own documentation told developers the keys were safe to leave unrestricted. It also ignores that Google's own engineering teams failed to restrict their keys, suggesting the problem is systemic rather than individual.
What Google Is Doing
Following the reclassification, Google committed to several remediation measures. Progress has been incremental.
Scoped defaults for AI Studio keys. New keys created through Google AI Studio will default to Gemini-only access rather than unrestricted access. This addresses new key creation but does not retroactively fix the millions of existing unrestricted keys already deployed.
Leaked key blocking. Google is implementing automatic blocking of API keys discovered in public code repositories and web content. When a key is identified as leaked, Google will disable Gemini access on that key automatically. The scope and detection methodology for this system have not been fully disclosed.
Proactive notification. Google plans to notify project owners when their API keys are found in public sources. This notification system is intended to alert administrators before an attacker discovers the key. The timeline for full deployment of this system remains unclear.
Root cause fix. The fundamental issue of retroactive privilege expansion when enabling new APIs on a project was still being addressed as of the disclosure date. A complete fix would require changing how API enablement interacts with existing key permissions, which is a significant architectural change to the Google Cloud credential system.
None of these measures address the core documentation problem. As of this writing, Google's Firebase documentation still states that API keys are not secret. The Maps JavaScript API documentation still shows keys embedded directly in HTML. Until Google updates this guidance, developers will continue deploying keys under the assumption that public exposure is acceptable.
What You Should Do Right Now
If your organization uses Google Cloud Platform in any capacity, the following actions should be taken immediately. Do not wait for Google's remediation to complete.
- Audit every GCP project for the Generative Language API. Navigate to APIs & Services > Enabled APIs in each project. If the Generative Language API appears in the list, every unrestricted key in that project has Gemini access. This includes projects where Gemini was enabled for testing purposes and never disabled.
- Identify all publicly exposed API keys. Search your website source code, JavaScript files, mobile app bundles and public repositories for strings matching the AIza format. Any key that appears in client-accessible code is a candidate for exploitation.
- Restrict every key to specific APIs. In the Cloud Console under APIs & Services > Credentials, select each key and set API restrictions. A Maps key should only access Maps APIs. A Firebase key should only access Firebase APIs. No public-facing key should have Gemini access unless that is its explicit purpose.
- Rotate any key that was publicly exposed while unrestricted. Restriction alone is not sufficient for keys that have already been harvested. Assume that any key in public HTML or a public repository has been copied. Generate a new key with proper restrictions and deploy it as a replacement.
- Enable billing alerts. Configure Cloud Billing alerts at aggressive thresholds to catch unauthorized Gemini usage early. A sudden spike in Generative Language API charges is the most visible indicator that a leaked key is being exploited.
- Separate GCP projects for sensitive APIs. Isolate Gemini and other high-sensitivity APIs in dedicated GCP projects that do not share keys with public-facing services. Your Maps project and your Gemini project should never be the same project. This prevents future API enablement from creating cross-service privilege escalation.
For organizations with large GCP footprints, this audit can be automated using the Cloud Asset Inventory API to enumerate all keys and their restrictions across projects. The Security Command Center can also flag unrestricted keys, though it may not specifically identify the Gemini exposure vector.
Why This Matters for Your Organization
If Google's own security team could not catch vulnerable keys on their own product websites, your team needs external validation. This is not a hypothetical concern. Google employs some of the best security engineers in the world and they missed this on their own infrastructure.
This vulnerability represents a growing attack class: privilege escalation through infrastructure changes. The attacker does not exploit a bug in your code. The attacker does not compromise your servers. The platform vendor changes the security properties of a deployed credential and the attacker takes advantage of the new permissions. Traditional vulnerability scanners do not detect this because there is no CVE to scan for. The "vulnerability" is a configuration state that was correct when it was deployed.
This is exactly the type of issue that API security testing and penetration testing catches. A competent tester will find your API keys in page source, test them against every Google API endpoint and report the exposure. Automated scanners check for known CVEs. Penetration testers check for business logic flaws and architectural weaknesses like this one.
Organizations that rely on AI-assisted development workflows face compounded risk. Developers using Gemini for code generation may have enabled the API on projects that also host public-facing services, creating the exact cross-pollination this vulnerability exploits. The move to enterprise AI coding makes proper API segmentation a board-level concern.
The broader lesson is that vendor documentation can become a liability. "API keys are not secret" was true when Google wrote it. It stopped being true when Gemini launched. Your security posture should not depend on vendor documentation remaining accurate indefinitely. Regular testing validates what is actually happening in your environment, not what the vendor says should be happening.
FAQ
Are Google API keys secrets?
Google's Firebase documentation still states that API keys are not secret. That guidance was accurate when API keys functioned only as project identifiers for billing. With the introduction of the Gemini API, unrestricted keys now authenticate to sensitive AI endpoints capable of reading private data and generating billable charges. Treat any API key with Gemini access as a secret credential regardless of what the documentation says.
How do I check if my Google API key can access Gemini?
Run a curl request against the Gemini files endpoint: curl "https://generativelanguage.googleapis.com/v1beta/files?key=YOUR_KEY". A 200 OK response means the key has active Gemini access. A 403 Forbidden response means the key is restricted or the Generative Language API is not enabled on the project. You should also check your GCP project under APIs & Services > Enabled APIs and confirm whether the Generative Language API is listed.
Can someone use my Maps API key to access my Gemini data?
Yes, if two conditions are met: the Generative Language API is enabled on the same GCP project and the key is unrestricted or has Gemini in its allowed API list. When Google enables the Gemini API on a project, every unrestricted key in that project silently gains access to Gemini endpoints. An attacker who copies your Maps key from public HTML can query the files and cachedContents endpoints to access uploaded data.
How do I restrict a Google API key?
In the Google Cloud Console, go to APIs & Services > Credentials. Click the key you want to restrict. Under "API restrictions," select "Restrict key" and choose only the specific APIs that key needs (for example, Maps JavaScript API only). Remove the Generative Language API from any publicly exposed key. After restricting, rotate the key to invalidate any copies that were harvested while the key was unrestricted.