The editorial argues Google has known about this default-configuration trap for years and chosen not to fix it at the product level. The Firebase console lets you enable Gemini against an unrestricted browser key with no warning, despite the key functioning as a bearer token for every enabled Google API including paid Gemini tiers.
The original poster's €54k bill in 13 hours demonstrates that Google's framing of the browser key as 'not a secret' is practically dangerous. The attacker simply scraped the key from the shipped JS bundle and pointed it at generativelanguage.googleapis.com, showing that without manually configuring API and HTTP referrer restrictions in the Cloud console, the key grants access to every enabled API on the project.
The editorial notes that GCP billing alerts are evaluated on a delay and frequently lag real spend by hours, making them useless against a flat-out Gemini abuse pattern that can rack up tens of thousands of euros before the first alert fires. Multiple HN reports of $5k-$100k+ incidents show this isn't an edge case but a repeated failure mode of the billing controls developers rely on.
On Google's own `discuss.ai.google.dev` forum, a developer posted a thread that every Firebase user should read before their next deploy. Their Firebase browser API key — the one Google tells you is safe to ship in client-side JavaScript — was extracted from a public web app and used to fire off a wall of Gemini API requests. In 13 hours, the bill hit €54,000.
The mechanics are ugly but simple. Firebase Web SDKs require an `apiKey` in the client config. Google's documentation has long reassured developers that this key is not a secret in the traditional sense: it identifies the project, not the caller, and Firebase security is supposed to come from Auth rules, App Check, and per-service restrictions. That framing is technically correct and practically dangerous. The same key can be scoped — via the Google Cloud API Key restrictions panel — to allow or deny specific APIs and specific HTTP referrers. If you never open that panel, the key is effectively a bearer token for every Google API your project has enabled, including the Gemini paid tier.
The victim had Gemini enabled for a legitimate feature. The attacker (or a bot farm; the thread is unclear) scraped the key from the shipped JS bundle, pointed it at `generativelanguage.googleapis.com`, and ran it flat out. Billing alerts — which in GCP are evaluated on a delay and frequently lag real spend by hours — fired too late to matter. The HN thread (359 points) is full of developers reporting near-identical incidents: $5k, $12k, $40k, one claim of six figures. The pattern repeats often enough that calling it an 'edge case' is generous.
This is not a novel vulnerability. It's a default-configuration failure that Google has been aware of for years and has chosen not to fix at the product level. The Firebase console happily lets you enable Gemini against an unrestricted browser key and shows no warning that you've just wired a metered LLM endpoint to a token you're about to paste into a `