Responding to Truffle's Research: Mitigating Exposed GCP Gemini Keys
Hey everyone,
I just finished reading the Truffle Security report regarding nearly 3,000 exposed Google Cloud API keys. It’s a stark reminder that an API key starting with "AIza" is often treated as a simple project identifier rather than a credential, but with the right APIs enabled, it's a golden ticket.
The core issue here is scope creep. Keys intended for benign services like Google Maps or Places can be abused to call the Generative Language API (Gemini) if that API is enabled on the parent project. Since these keys are often hardcoded in client-side JS, they are trivial to scrape.
I've started auditing our repos, but I'm also looking at runtime defenses. If you find a leaked key, you immediately need to check if the Generative Language API is enabled on that project. Here is a quick snippet to list enabled APIs for a specific project:
gcloud services list --enabled --project=YOUR_PROJECT_ID --filter="name:generativelanguage.googleapis.com"
Additionally, enforcing Application Restrictions in the GCP Console is critical, but I'm finding it hard to automate the verification of those settings across multiple projects. Does anyone have a script or a tool that can programmatically audit whether an API key is restricted by IP or HTTP Referrer?
How are you guys handling the sanitation of these keys in your legacy front-end applications?
We strictly separate keys by environment and scope. Client-side keys should never have access to Generative AI endpoints. If you must use them on the frontend, set up an Application Restriction in the Google Cloud Console under "API Keys > Application Restrictions". This limits requests to specific IP addresses or HTTP referrers (your domain). It's not foolproof ( Referer headers can be spoofed), but it stops bulk scraping.
For detection, I'm not just looking at the keys, but monitoring the usage. If you send Cloud Audit Logs to SIEM, you can catch this. Query for methodName related to Generative Language and filter for authenticationInfo.principalEmail containing the project ID or "@cloudservices.gserviceaccount.com". Here is a basic KQL query for Sentinel:
CloudAuditLogs
| where ServiceName == "aiplatform.googleapis.com"
| where MethodName contains "predict"
| project Timestamp, ResourceName, PrincipalEmail
This helps you spot if a 'billing-only' key suddenly starts chatting with Gemini.
I use TruffleHog (the same tool Truffle Security makes) for scanning our CI/CD pipelines. It's great at catching high-entropy strings. You can run it locally to check those client-side bundles before deployment:
trufflehog filesystem --directory ./src-web --only-verified
Remember though, detection is only half the battle. The real fix is architectural: move any AI calls to a backend proxy. Never let the frontend talk directly to GCP with a privileged key.
Building on the prevention strategies, it’s vital to audit exactly which APIs your existing keys can reach. Often, legacy keys accumulate permissions over time. I recommend using the gcloud CLI to inspect restrictions before an incident occurs:
gcloud services api-keys lookup KEY_STRING --format="value(restrictions)"
This quickly reveals if a client-side key has generativelanguage.googleapis.com enabled. If it does, rotate it immediately; restrictions are your last line of defense, but verifying them is often overlooked.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access