I am posting this to the community because this issue represents a systemic vulnerability affecting the Firebase, Google Cloud, and Gemini developer ecosystems. Google needs to address this structurally before it severely damages developer trust.
The Issue: Public Keys with Overly Broad API Access
Our Google Cloud project was recently suspended after activity was flagged as “consistent with hijacking.” At the same time, our billing account was hit with unexpected charges for Gemini / Generative Language API usage that we did not authorize or benefit from.
The apparent culprit appears to be an auto-generated Google API key associated with our Firebase client-side configuration.
Here is why this is a critical platform-level problem:
1. The public nature of Firebase keys
Firebase API keys are historically documented and treated as public-facing identifiers. They are intentionally embedded in client-side apps.
2. The overly broad API access risk
Firebase browser keys are public/client-side keys. If their API restrictions are missing, too broad, or include Gemini / Generative Language APIs, they can become usable for paid AI calls.
3. The exploitation risk
If a developer enables Gemini within their project but forgets to retroactively apply strict API restrictions to existing public Firebase keys, anyone can extract that public key from the client app and potentially execute high-cost Generative AI requests on the developer’s dime.
The Support Catch-22: Remediation vs. Suspension
The frustration of the financial hit is compounded by an operational gridlock in Google’s security workflow:
-
Google flags the project as compromised due to API key abuse.
-
Google completely suspends project access.
-
Google leaves the developer with the bill, but blocks console access, making it impossible to audit logs, rotate credentials, delete compromised keys, or properly remediate the issue.
This creates an unsustainable loop where developers are punished for a security incident, then locked out of the tools required to fix it while waiting days for an asynchronous Account and Security review.
Actionable Recommendations for Google
We are not looking to evade developer responsibility. We agree that developers must set budgets, monitor usage, and restrict keys. However, when a platform optimizes for rapid deployment and integrates high-cost AI services, the safe path must be the default path.
We urge the Google Cloud and Firebase product teams to implement the following changes:
1. Product and Architecture Defaults
Automatic AI API isolation
Automatically exclude high-cost APIs like Generative Language / Gemini from public browser, Android, iOS, or Firebase-generated keys unless explicitly enabled.
Proactive scanning
Flag projects where a public-facing key has unrestricted access to billable AI APIs and trigger a dashboard warning.
2. Policy and Support Workflow
Sandbox remediation access
Provide a restricted, read/write administrative access state for suspended projects, allowing developers to rotate or delete keys without re-enabling malicious traffic.
Fast-track abuse remediation
Create an expedited support path specifically for AI billing and API key abuse, separate from standard billing disputes.
Automatic billing review
Provide billing adjustments or credits when Google’s own automated systems flag the traffic as compromised or hijacked.
Overall, Google has spent over a decade building incredible goodwill through Firebase and the Google Cloud ecosystem. Gemini is a powerful tool, but if developers begin to associate building with Gemini with catastrophic financial risks and sudden project lockouts, adoption will suffer.
Google needs to address this proactively with clearer defaults, guardrails for legacy keys, and a fairer remediation process.
Note to Google Staff: Project ID is available privately upon request