Google API keys weren't secrets, but then Gemini changed the rules

Security researchers at Truffle Security have uncovered a critical privilege escalation vulnerability in Google Cloud's API key system, where the launch of the Gemini AI API fundamentally changed the security model of existing API keys. For over a decade, Google instructed developers that API keys (like those used for Maps and Firebase) were safe to embed in client-side code, treating them as public identifiers rather than secret credentials. However, when developers enable the Gemini API on a Google Cloud project, all existing API keys in that project—including those publicly exposed in websites—silently gain access to sensitive Gemini endpoints without any notification or confirmation. This retroactive privilege expansion means thousands of keys deployed as harmless billing tokens have become live Gemini credentials.

The vulnerability stems from Google using a single API key format (AIza...) for both public identification and sensitive authentication, combined with insecure defaults where new keys default to 'Unrestricted' access. Researchers scanned millions of websites and found nearly 3,000 Google API keys that now authenticate to Gemini despite being deployed for public services. With a valid key, attackers can access uploaded files, cached data, and charge LLM usage to victim accounts—even Google themselves had old public API keys that could access their internal Gemini systems. The core issue represents a failure of safe defaults and incorrect privilege assignment, where keys designed for one purpose were silently granted powerful new capabilities without developer awareness.