Google API Keys Weren't Secrets—Until Gemini Quietly Changed the Rules
Key Takeaways
- ▸Nearly 3,000 Google API keys originally deployed for public services like Maps now inadvertently grant access to sensitive Gemini endpoints
- ▸Google's API key architecture violates secure design principles by using a single key format (AIza...) for both public identification and sensitive authentication
- ▸Enabling the Gemini API on a Google Cloud project silently grants existing API keys access to Gemini without warning developers
Summary
Security researchers at Truffle Security have uncovered a significant vulnerability in Google's API key architecture that affects thousands of developers. For over a decade, Google explicitly advised developers that API keys for services like Maps and Firebase were not secrets and could safely be embedded in public client-side code. However, when Google introduced the Gemini API, existing API keys in projects where Gemini was enabled silently gained authentication privileges to sensitive Gemini endpoints—with no warning, notification, or confirmation dialog to developers.
The researchers scanned millions of websites and discovered nearly 3,000 Google API keys originally deployed for public services that now also authenticate to Gemini. These keys, sitting in plain sight in website source code, can be used by attackers to access uploaded files, cached data, and charge LLM usage to victims' accounts. Even Google's own internal systems were affected, with old public API keys that could be used to access Google's internal Gemini instances. The vulnerability stems from Google Cloud using a single API key format (AIza...) for two fundamentally different purposes: public identification and sensitive authentication.
The core issue is what security experts call "retroactive privilege expansion." A developer who embedded a Maps API key in their website three years ago—following Google's own documentation—could find that key transformed into a Gemini credential months or years later when a team member enabled the Gemini API for an unrelated project. The problem is compounded by insecure defaults: new API keys in Google Cloud default to "Unrestricted," meaning they're immediately valid for every enabled API in the project, including Gemini. This represents a critical failure in secure API design, where the principle of least privilege and separation of credentials for different security contexts should be foundational.
- Attackers can trivially extract these keys from public website source code and use them to access private files, cached data, and charge AI usage to victims' accounts
- The vulnerability affects keys that were correctly deployed according to Google's own documentation, which explicitly stated API keys were "not secrets"
Editorial Opinion
This revelation exposes a fundamental tension in cloud platform design between developer convenience and security architecture. While Google's original stance that Maps API keys weren't secrets made sense for their intended purpose, the company's failure to architect Gemini with separate credential types—or at minimum, to notify developers when existing keys gained new privileges—represents a significant security design flaw. The fact that even Google's own internal systems were vulnerable underscores how thoroughly this issue was overlooked. As AI services become increasingly integrated into existing cloud platforms, this incident should serve as a wake-up call about the dangers of credential reuse and the critical importance of explicit privilege boundaries.
