Google Maps Keys Abused to Leak Gemini AI Data
We've treated hardcoded Google Maps API keys in client-side JS as a low-risk infosec issue for years—usually just quota abuse or minor billing concerns. However, the latest research from Wiz reveals a significant impact scope: these keys are authenticating against the Gemini AI API endpoints.
Because of how Google's infrastructure handles authentication and scoping, a key intended for the Maps JavaScript API can apparently be used to hit generativelanguage.googleapis.com. If an attacker scrapes a key from a website's source code, they can potentially query the model and access data generated or stored by that specific API identity.
Detection & Hunting
If you are exposing Google API keys in your front-end, you need to audit your usage immediately. Start by checking your Cloud Console for unrestricted keys.
Here is a KQL query to hunt for unauthorized access to Gemini endpoints via specific keys in your proxy logs:
DeviceNetworkEvents
| where RemoteUrl contains "generativelanguage.googleapis.com"
| where RequestHeaders contains "X-Goog-Api-Key"
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessAccountName
| order by Timestamp desc
Remediation
You must enforce application restrictions (HTTP referrer, IP addresses) on all API keys in the Google Cloud Console. Do not rely on obscurity.
How is everyone else handling the sprawl of API keys in legacy front-end apps? Are you rotating keys en masse, or just waiting for an automated tool to catch it?
This is a classic scope creep issue. We've been using a script similar to this in our CI/CD pipeline to catch keys before they hit prod. It uses truffleHog but is specifically tuned for Google's patterns:
git diff --name-only HEAD~1 HEAD | xargs trufflehog --regex --entropy=False --exclude_paths=.github/
If you aren't scanning your repo history for these, you're basically leaving the keys in the parking lot with the engine running.
I tested this in our lab environment. The impact is real. If you have an API key with 'Generative Language API' enabled (which many Maps keys inherit by default depending on the project setup), an actor can use it.
I verified the request via curl:
curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-pro:generateContent?key=YOUR_KEY" \
-H 'Content-Type: application/' \
-d '{"contents":[{"parts":[{"text":"Hello"}]}]}'
It returned a 200 OK. Immediate rotation is the only safe path if those keys were public.
From a SOC perspective, we are struggling to distinguish between legitimate usage and abuse. The user agent is usually just google-api-python-client or standard browser headers.
We are currently correlating the IP addresses hitting the Gemini API with our known office egress IPs. Anything else gets blocked. It's noisy, but better than the alternative of data exfiltration via AI prompts.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access