€54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

An exposed Firebase browser API key linked to Google’s Gemini AI services led to €54,000 in charges within 13 hours, highlighting how easily unrestricted keys and delayed billing alerts can generate life‑altering bills. Commenters criticize Google and other major cloud providers for lacking hard, enforceable spending caps, relying instead on slow notifications and complex DIY safeguards that small teams rarely configure correctly. The incident also underscores a broader security problem: keys long treated as “public identifiers” for services like Firebase or Maps can now unlock powerful, billable AI APIs, creating both financial and data‑exposure risk.

Incident and suspected cause

  • A Firebase “browser key” without API restrictions was used to make massive Gemini API calls, causing a ~€54k spike in 13 hours.
  • Many infer the key was exposed client-side (standard for Firebase), making it easy to harvest and abuse.
  • Similar billing-surprise stories are cited (thousands to tens of thousands in charges) for Gemini and other GCP services.

Lack of hard caps and delayed alerts

  • Core complaint: GCP, AWS, and Azure generally provide alerts and “soft” budget tools, but not strict, unbreakable spend caps.
  • Budget and anomaly alerts can lag by hours or more; by the time they fire, damage is often done.
  • Some note Gemini recently added spend caps and “prepay” options, but they default to off, and enforcement still has ~10-minute lag.

API keys: public vs secret confusion

  • Firebase and Google Maps keys have long been documented and treated as “public by design” identifiers, not secrets.
  • Gemini later reused these APIs/keys for LLM access and billing, breaking that mental model.
  • Docs were quietly updated to say such keys must be restricted and not used for Gemini or other non-Firebase APIs.
  • Many argue Google should have created separate, non-interchangeable public vs private key types.

Security and data exposure

  • Discussion stresses this is not only a billing issue: the same keys can access Gemini files and cached context, potentially leaking user data.
  • Public keys scraped from web or GitHub can thus be used both to incur costs and to read AI-related project data.

Google’s incentives and response

  • Many believe the lack of hard caps and slow action is driven by revenue incentives, not technical limits.
  • Others counter that billing aggregation at cloud scale is complex and inherently laggy, and that providers sometimes waive surprise bills as a workaround.
  • Some see Google’s muted, slow remediation as evidence of embarrassment over a serious design failure.

Mitigations and alternatives

  • Recommended mitigations:
    • Restrict Firebase keys to Firebase-only APIs in the console.
    • Apply Gemini-specific spend caps and/or quotas.
    • Use Pub/Sub + Cloud Functions to auto-disable billing as an “emergency brake.”
    • Move Gemini calls server-side, never exposing private keys.
    • For risk-averse users, consider prepaid or hard-capped services (e.g., some smaller clouds, OpenAI-style credits, VPS hosting).