Your Google Maps API key might be a security vulnerability. And you probably don't even know it.
The Problem
Google Cloud uses a single API key format (AIza...) for two fundamentally different purposes:
- Public identification (Maps, Firebase, etc.) - designed to be embedded in client-side code
- Sensitive authentication (Gemini AI API) - should NEVER be public
For over a decade, Google explicitly told developers that API keys are not secrets and safe to embed in HTML/JavaScript. Firebase's security checklist stated this. The Maps documentation instructs you to paste keys directly into your website.
Then Gemini changed everything.
The Retroactive Privilege Escalation
Here's the attack scenario:
- Three years ago: You created a Google Maps API key and embedded it in your website's HTML (exactly as Google instructed)
- Last month: A developer on your team enabled the Gemini API for a prototype
- Now: Your public Maps key automatically gained access to sensitive Gemini endpoints
- The catch: Nobody told you
The key went from a harmless billing identifier to a credential that can:
- Access your uploaded files and datasets
- Read cached Gemini content
- Rack up thousands of dollars in AI usage charges
- Exhaust your API quotas
The Attack is Trivial
An attacker just needs to:
# Visit your website, view source, copy your AIza... key
# Then run:
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$STOLEN_KEY"
# If you get 200 OK instead of 403 Forbidden, they have access
No sophisticated hacking. Just scrape a public key and call the API.
The Scale: 2,863 Live Keys Exposed
Truffle Security scanned the November 2025 Common Crawl dataset (~700 TiB of web content) and found 2,863 live Google API keys vulnerable to this attack.
These aren't just hobby projects. Victims included:
- Major financial institutions
- Security companies
- Global recruiting firms
- Google itself (yes, even Google had vulnerable keys)
If Google's own engineering teams can't avoid this trap, expecting every developer to navigate it correctly is unrealistic.
Proof of Concept: Google's Own Infrastructure
Truffle Security found a Google API key embedded in a Google product's public website since February 2023 (before Gemini existed). It was used solely as a public identifier for Maps.
When they tested it against the Gemini API:
curl "https://generativelanguage.googleapis.com/v1beta/models?key=$KEY"
# Response: 200 OK - full list of available models
A key deployed years ago for a benign purpose had silently gained full access to a sensitive API without any developer intervention.
Why This Happened
The vulnerability stems from three design flaws:
1. Insecure Defaults (CWE-1188)
When you create a new API key in Google Cloud, it defaults to "Unrestricted" - immediately valid for EVERY enabled API in the project, including Gemini.
The UI shows a warning, but the architectural default is wide open.
2. Incorrect Privilege Assignment (CWE-269)
Keys retroactively gained sensitive privileges:
- You create a key for Maps (harmless)
- Someone enables Gemini API (key now has sensitive access)
- You're never warned
3. Lack of Key Separation
Secure API design requires distinct keys for different purposes:
- Publishable keys (public, client-side)
- Secret keys (server-side only)
Google uses one key format for both, inviting confusion and compromise.
Google's Response
Truffle Security reported this on November 21, 2025. After initial pushback, Google:
- Reclassified it from "Customer Issue" to "Bug"
- Expanded leaked-credential detection pipeline
- Began restricting exposed keys from Gemini access
- Committed to root-cause fixes
Google's roadmap includes:
- Scoped defaults for new keys (Gemini-only access)
- Blocking leaked keys proactively
- Customer notifications for discovered leaks
What You Should Do RIGHT NOW
Step 1: Check for Gemini API
# Go to GCP Console
# Navigate to: APIs & Services > Enabled APIs & Services
# Look for "Generative Language API"
If it's not enabled, you're not affected by this specific issue.
Step 2: Audit Your API Keys
Navigate to APIs & Services > Credentials and check:
- Keys with warning icons (unrestricted)
- Keys explicitly allowing Generative Language API
Step 3: Verify Keys Aren't Public
This is critical. Check:
- Client-side JavaScript bundles
- Public GitHub repositories
- Any HTML/JS files on your website
Start with your oldest keys first - they're most likely to have been deployed publicly under the old "API keys are safe" guidance.
Step 4: Rotate Exposed Keys
If you find an exposed key:
- Create a new restricted key
- Update your application
- Delete the old key
- Scan for any other instances
Bonus: Automated Scanning
Use TruffleHog to scan your code and infrastructure:
trufflehog filesystem /path/to/your/code --only-verified
This will verify whether discovered keys are live and have Gemini access.
The Bigger Picture
This isn't just about Google. As organizations bolt AI capabilities onto existing platforms, legacy credentials expand their attack surface in ways nobody anticipated.
The pattern: public identifiers quietly gaining sensitive privileges.
Key Takeaways
- API keys can now be secrets - The old guidance is outdated
- Check your GCP projects immediately - Even old keys might be exposed
- Restrict all API keys - Never use unrestricted keys
- Separate public and private keys - Different purposes need different credentials
- Scan your codebase - Tools like TruffleHog can find leaks
Timeline
- Nov 21, 2025: Truffle Security reports to Google VDP
- Dec 2, 2025: Google reclassifies as "Bug," begins remediation
- Jan 13, 2026: Classified as "Single-Service Privilege Escalation, READ" (Tier 1)
- Feb 19, 2026: 90-day disclosure window ends
- Feb 26, 2026: Public disclosure
This is a wake-up call. The security assumptions we made years ago about API keys no longer hold. As AI services proliferate, the attack surface of legacy credentials grows.
Check your keys. Restrict your keys. Rotate your keys.
Your private data depends on it.
Resources: