The original poster experienced €54,000 in charges over 13 hours because a standard Firebase browser key — which Google's own docs say is safe to expose — was exploited to access Gemini APIs. Their post argues that Google's default configuration silently turns a public project identifier into an unlimited billing liability.
The editorial highlights a core design tension: Firebase was built around public API keys that rely on backend security rules, but Gemini APIs have no per-request authorization layer. Enabling paid generative AI endpoints on the same unrestricted keys breaks the security model Firebase was designed around.
The editorial implicitly argues that even if key restrictions are the user's responsibility, a 13-hour window accumulating €54K without any automated circuit breaker or billing alert represents a failure of platform-level safety. Cloud providers have the data to detect anomalous spend patterns and should act on them.
The editorial acknowledges that Google documents the need for API restrictions and referrer limitations on browser keys. The developer's key had no restrictions configured, which is a known misconfiguration. The tools to prevent this exist — they just weren't applied.
The editorial emphasizes that every Firebase web app ships a browser key in client-side JavaScript, and the moment Gemini API access is enabled on a project, that key becomes exploitable. This isn't one developer's oversight — it's a default configuration that puts every Firebase project with AI features at risk.
A developer posted on Google's AI developer forum describing a billing nightmare: €54,000 in Gemini API charges accumulated in just 13 hours. The root cause was a Firebase browser key — the kind embedded in client-side JavaScript for every Firebase project — that had no API restrictions configured. An unknown party discovered the key and used it to make high-volume requests to Google's Gemini APIs.
Firebase browser keys are not secrets. They're shipped in every web app's Firebase config object, visible in page source to anyone with a browser's dev tools. Google's own documentation says this is fine — these keys are meant to identify your project, not authenticate users. The security model relies on Firebase Security Rules and API restrictions to limit what a key can actually do.
The problem: Google now lets these same browser keys access paid generative AI APIs, and the default configuration has no restrictions. A key created for Firebase Auth or Firestore — services with their own authorization layers — can silently become a billing liability the moment Gemini API access is enabled on the project.
This incident exposes a design tension that Google hasn't resolved cleanly. Firebase was built around the idea that API keys are public identifiers, not credentials. For years, this worked because the services behind those keys (Realtime Database, Firestore, Storage) all enforced their own security rules. The key gets you to the door; the rules decide if you get in.
Generative AI APIs don't work that way. There are no per-document security rules for a Gemini completion request. If your key can reach the Gemini endpoint and you haven't set referrer restrictions, anyone with that key can run up your bill. The API doesn't know or care whether the request came from your app or from a script in someone's terminal.
The community response on Hacker News (366 points and climbing) reflects a mix of sympathy and frustration. Several commenters pointed out that Google's own Firebase setup tutorials don't emphasize the billing risk of unrestricted keys when AI APIs are in the mix. Others noted that Google Cloud does offer billing alerts and quota limits, but these are configured in a completely different console from Firebase, creating a gap that less experienced developers fall into.
This isn't the first time cloud billing surprises have made headlines, but the speed is notable. €54,000 in 13 hours means roughly €70 per minute — the kind of burn rate that exceeds most developers' billing alert thresholds before the alert even fires. By the time you get the email, you're already deep in the hole.
To understand why this keeps happening, look at the chain of defaults:
1. Firebase project creation generates a browser API key automatically. 2. The key is embedded in client-side config — `firebaseConfig.apiKey` — and Google's docs say this is expected behavior. 3. Gemini API is enabled on the project, either explicitly or through Firebase AI features. 4. No API restrictions are set on the key — no HTTP referrer limits, no API service allowlist. 5. No billing cap is configured — Google Cloud doesn't offer hard spending limits on most services, only alerts.
Each step is individually reasonable. Together, they create a path where a public identifier becomes an unlimited credit card.
The fix is straightforward but requires deliberate action across multiple Google consoles. In the Google Cloud Console (not the Firebase Console), you need to navigate to APIs & Services → Credentials, find the browser key, and add both HTTP referrer restrictions (limiting which domains can use the key) and API restrictions (limiting which services the key can access). If your app doesn't need Gemini from the client side, remove Gemini API from the key's allowed services entirely.
For billing protection, set up budget alerts in Google Cloud Billing — but understand their limitation. Alerts notify you when spending crosses a threshold; they do not stop the spending. To actually halt runaway costs, you need to either use quota limits on the specific API or implement a Cloud Function that disables billing programmatically when triggered. Google documents this pattern but doesn't make it a default.
If you're running any Firebase project with Gemini or Vertex AI APIs enabled, audit your API keys today. Specifically:
- Check every key in Google Cloud Console → APIs & Services → Credentials. Look for keys with "None" under Application restrictions and "Don't restrict key" under API restrictions. These are the liability. - Set HTTP referrer restrictions on any key used in browser code. Lock it to your production domains. - Create separate keys for server-side AI calls. Never reuse a Firebase browser key for Gemini requests from your backend. Server keys should use IP restrictions instead of referrer restrictions. - Set up billing alerts at multiple thresholds — and build or deploy the programmatic billing kill switch. A $100/day alert won't help if you're burning $70/minute. - Consider proxying AI requests through your backend. Instead of calling Gemini directly from the client with a browser key, route requests through your server where you control rate limiting, authentication, and can use a restricted server key.
This last point is the real architectural takeaway. Client-side AI API calls with browser keys are a footgun that no amount of key restriction fully mitigates — the only robust pattern is to proxy through your own backend where you control the rate limiter. Referrer restrictions help, but they can be spoofed. Your server is the only chokepoint you truly control.
Google will likely tighten defaults here — the optics of a €54K surprise bill from a browser-visible key are bad for Firebase adoption, especially as Google pushes Gemini integration deeper into the Firebase ecosystem. But waiting for Google to fix this is not a strategy. The developer in this story is now negotiating with Google Cloud billing support, with no guarantee of a full reversal. The 13-hour window between exploitation and discovery is a reminder that in the pay-per-request AI era, the cost of a misconfigured key isn't a slow leak — it's a fire hose.
> We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours. By the time we reacted, costs were already around €28,000.I had a similar experience with GCP where I set a budget of $100 and was only emailed 5 hours after exceeding the budget by which
Considering the amount of repositories on public GitHub with hard-coded Gemini API tokens inside the shared source code (https://github.com/search?q=gemini+%22AIza%22&type=code), this hardly comes as a surprise. Google also has historically treated API keys as non-secrets, except
As others have said, this is a "feature" for Google, not a bug. There is no easy way to set a hard cap on billing on a project. I spent the better time of an hour trying to find it in the billing settings in GCP, only to land on reddit and figuring out that you could set a budget alert to
I read the following [0] and immediately went to my firebase project to downgrade my plan. This is horrific.> Yes, I’m looking at a bill of $6,909 for calls to GenerativeLanguage.GenerateContent over about a month, none of which I made. I had quickly created an API key during a live Google traini
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours> By the time we reacted, costs were already around €28,000> The final amount settled at €54,000+ due to delayed cost reportingSo much for the folks defending these three companies tha