Google's API Security Shift Exposes Thousands to Data Breach Risks

Google spent over a decade telling developers that API keys are not secrets. But that's no longer true: Gemini accepts the same keys to access private data. Truffle Security, a startup focused on secret scanning technology, discovered that thousands of Google API keys deployed for public services like Maps can now authenticate to Google's Gemini API without any warning.

The vulnerability stems from Google's use of a single API key format (AIza...) for fundamentally different purposes: public identification and sensitive authentication. For years, Google explicitly instructed developers to embed these keys directly in client-side code, with Firebase's own security checklist stating that API keys are not secrets.

The problem emerged when Google introduced the Gemini API. When enabled on a Google Cloud project, existing API keys—including those sitting in public JavaScript on websites—silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification.

"This creates two distinct problems," explains Joe Leon, security researcher at Truffle Security. "Retroactive Privilege Expansion and Insecure Defaults. 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."

Truffle Security scanned the November 2025 Common Crawl dataset and identified 2,863 live Google API keys vulnerable to this privilege-escalation vector. 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," Leon noted.

The attack vector is straightforward. An attacker visits a website, views the page source, copies the AIza... key from a Maps embed, and makes requests to the Gemini API. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to the victim's account.

Truffle Security reported this to Google through their Vulnerability Disclosure Program on November 21, 2025. After initially dismissing the issue as "intended behavior," Google reclassified it as a bug after Truffle provided concrete examples from Google's own infrastructure.

Google has since documented their roadmap for addressing the issue, including scoped defaults for new keys, leaked key blocking, and proactive notification systems. However, the root cause fix remains in progress.

For organizations using Google Cloud services, Truffle Security recommends three immediate steps:

1. Check every GCP project for the Generative Language API
2. Audit API keys for unrestricted access or explicit Gemini permissions
3. Verify none of those keys are public in client-side code, repositories, or other internet-accessible locations

Truffle Security, founded in 2021, has developed TruffleHog, an open-source secret scanning tool that can detect exposed API keys and verify their access levels. The company has positioned itself in the growing DevSecOps market, addressing the increasing security challenges in modern software development.

This vulnerability highlights a broader pattern as organizations bolt AI capabilities onto existing platforms, expanding the attack surface for legacy credentials in ways that weren't anticipated. As AI services become more prevalent, the security community will need to develop new approaches to credential management that distinguish between public identifiers and sensitive authentication tokens.

For more information on how to protect your organization, you can attend Truffle Security's webinar on this topic or use their TruffleHog tool to scan your code for exposed keys.

Additional resources:

• Google's API key documentation
• Firebase security guidelines
• TruffleHog GitHub repository