Abrechnungsexplosion von 54.000 € in 13 Stunden: Gemini-API-Aufrufe über einen uneingeschränkten Firebase-Browser-Schlüssel

• Ein offengelegter Firebase-Browser-Schlüssel ohne API-Beschränkungen führte dazu, dass extern automatisch Gemini-API-Anfragen ausgelöst wurden, was innerhalb kurzer Zeit massive Kosten verursachte
• Unabhängig vom tatsächlichen Nutzer-Traffic wurden in 13 Stunden mehr als 54.000 € berechnet; zudem wurden Kostenwarnungen verspätet ausgelöst, wodurch sich die Reaktion verzögerte
• Das Google-Cloud-Supportteam stufte die Anfragen als gültige Nutzung (valid usage) ein und lehnte eine Gebührenanpassung ab
• Google führt Schutzmechanismen wie Ausgabenlimits, Auth-Schlüssel, automatische Schlüsselsperrung und Prepaid-Abrechnung ein und will die Nutzung uneingeschränkter Schlüssel schrittweise beenden
• Entwickler sollten keine Schlüssel in Client-Code einbetten und unbedingt API-Key-Beschränkungen sowie Budgetlimits konfigurieren

---

Fall eines sprunghaften Anstiegs der Gemini-API-Abrechnung durch einen offengelegten Firebase-Browser-Schlüssel

• Überblick über den Vorfall

  • In einem Projekt, das bislang nur Firebase Authentication nutzte, stieg die Gemini-API-Nutzung direkt nach der Aktivierung von Firebase AI Logic stark an
  • Unabhängig vom tatsächlichen Nutzer-Traffic entstanden in kurzer Zeit automatisierte Anfragen, die innerhalb von rund 13 Stunden zu Kosten von mehr als 54.000 € führten
  • Nach der Deaktivierung der API und der Rotation der Zugangsdaten (credentials) stoppte der anomale Traffic
  • Budgetwarnungen (€80) und Warnungen zur Erkennung von Kostenanomalien wurden erst mit mehreren Stunden Verzögerung ausgelöst; zum Zeitpunkt der Reaktion waren bereits Kosten von etwa 28.000 € entstanden
  • Der endgültige Rechnungsbetrag wurde aufgrund der verzögerten Kostenberichterstattung auf mehr als 54.000 € festgesetzt

• Ergebnis des Google-Cloud-Supports

  • Obwohl Logs und Analysen eingereicht wurden, wurden die Anfragen als gültige Nutzung (valid usage) aus dem Projekt eingestuft, wodurch der Antrag auf Gebührenanpassung abgelehnt wurde
  • Obwohl diese Nutzung anomaler Natur war und nicht durch Nutzer-Traffic verursacht wurde, wurde sie systemseitig als regulär abrechenbar behandelt

• Fragen des Nutzers

  • Es wurde gefragt, ob es nach der Aktivierung von Firebase AI Logic oder Gemini ähnliche Fälle gegeben hat
  • Außerdem wurde nach zusätzlichen Schutzmaßnahmen neben App Check, Quoten und einem Wechsel zu serverseitigen Aufrufen gefragt
  • Ebenfalls wurde nach einem weiteren Eskalationsweg (escalation path) für solche Fälle gefragt

Antwort von Google (Logan Kilpatrick)

• Abrechnungs- und Nutzungsbegrenzungsfunktionen

  • Für Gemini-API-Nutzer wurden Abrechnungslimits für Billing-Konten (billing account caps) eingeführt; Tier-1-Nutzer werden nach einem monatlichen Limit von 250 $ automatisch blockiert
  • Projektbezogene Ausgabenlimits (project spend caps) können konfiguriert werden; als Beispiel wurde für ein persönliches Konto ein Limit von 50 $ gesetzt
  • Bei allen Abrechnungsberichten gibt es eine Verzögerung von etwa 10 Minuten

• API-Key-Sicherheit und Änderungen

  • Die Verwendung uneingeschränkter API-Keys (unrestricted key) soll für die Gemini API bald deaktiviert werden

    • Für neue Nutzer wird standardmäßig ein Auth-Schlüssel (Auth key) erstellt, der gegenüber früher stärker abgesichert ist
    • Schlüssel sollten nicht in Client-Code eingebettet werden, da bei einer Offenlegung Kosten entstehen können
    • Es gibt eine Funktion, bei der auf öffentlichen Websites offengelegte Schlüssel automatisch erkannt und deaktiviert werden; in tatsächlichen Fällen wurden sie innerhalb weniger Minuten gesperrt

• Schlüsselbeschränkungen und Serviceumfang

  • In Google AI Studio erstellte Schlüssel sind standardmäßig auf die Gemini API beschränkt

    • Dagegen können über andere Wege wie die Google Cloud Console erstellte Schlüssel auf mehrere Services zugreifen; bei Bedarf müssen servicebezogene Beschränkungen gesetzt werden

• Zusätzliche Maßnahmen und künftige Pläne

  • Zur Prüfung des Vorfalls wurde um direkte Kontaktaufnahme per E-Mail ([e-mail]) gebeten
  • Ein Modell für Prepaid-Abrechnung (prepaid billing) wurde eingeführt, um auf ein Bezahlen vor Nutzung umzustellen
  • Es ist derzeit bereits auf neue Konten in den USA angewendet und wird schrittweise weltweit ausgerollt
  • Ziel dieser Maßnahmen ist es, die Kostenkontrolle für Entwickler zu stärken und unerwartete Abrechnungen zu verhindern

[GN⁺]

Hacker-News-Kommentare

• Wir hatten Budget-Benachrichtigungen (€80) und Kostenüberschreitungswarnungen eingerichtet, aber beide wurden erst mit mehreren Stunden Verzögerung ausgelöst.
  Als wir reagierten, lagen die Kosten bereits bei €28.000, und durch die verzögerte Kostenmeldung wurden am Ende mehr als €54.000 berechnet.
  Die Ausrede der drei Unternehmen, ein „hartes Ausgabenlimit sei technisch unmöglich“, ist in so einer Situation nicht überzeugend.

  • Deshalb nutze ich Dienste wie Google Cloud möglichst nicht.
    Dass ein Hard Cap unmöglich sein soll, ergibt keinen Sinn, und wenigstens sollte man den Nutzern die Wahl lassen.
  • Das ist wirklich absurd. Wenn man an einem guten Projekt arbeitet und wegen eines einzigen Fehlers plötzlich €30.000 bis €50.000 zahlen soll, ist das ein einschneidender Schlag fürs Leben.
    Früher war so etwas einfach ein Bug, heute kann es in den Bankrott führen.
  • So etwas sollte illegal sein.
    Wenn ich den Austausch der Badezimmerfliesen beauftrage und mir stattdessen die Neugestaltung des Gartens berechnet wird, sollte ich selbstverständlich das Recht haben, das abzulehnen.
  • Als Manager meide ich Google Cloud wegen solcher Kundendienst-Katastrophen.
    Andererseits verstehe ich aus meiner Erfahrung mit Abrechnungssystemen von Telekommunikationsanbietern, dass die Auswertung von Logs im TB-Bereich Zeit braucht.
    Allerdings kalkulieren Telekommunikationsanbieter üblicherweise mit 2–3 % Forderungsausfällen und gehen kundenfreundlicher damit um.
    Google sollte in solchen Fällen deutlich eleganter reagieren.
    Vor allem wenn das direkt nach dem Offenlegen eines AI-Schlüssels passiert ist, hätte Google das Key-Scanning erkennen und blockieren müssen.
  • Laut der Gemini-API-Dokumentation kann man monatliche Ausgabenlimits sowohl auf Projekt- als auch auf Abrechnungskonto-Ebene festlegen.
    In der Praxis scheint diese Funktion aber nicht korrekt zu funktionieren.

• Ich hatte eine ähnliche Erfahrung.
  Ich hatte in GCP ein Budget von $100 gesetzt, bekam die E-Mail-Benachrichtigung aber erst 5 Stunden nach der Überschreitung.
  Erstaunlich, dass so eine Funktion keine Priorität hat.
  Kurzfristig sinken dadurch vielleicht Googles Einnahmen, aber Entwickler mit solchen Erfahrungen werden den Dienst nie wieder empfehlen.

  • Jedes Mal, wenn ich so etwas höre, macht mich das wütend.
    Unser Zwei-Personen-Team wäre wegen eines runaway jobs fast untergegangen.
    Wir hatten Warnungen und einen Kill Switch nach der von GCP empfohlenen Methode gekoppelt, aber die Warnung kam 6 Stunden zu spät.
    Am Ende bekamen wir die Rückerstattung nur, nachdem wir Beweise vorgelegt hatten.
    Google sagte, die Pipeline sei wegen zu vieler Line Items ins Stocken geraten, aber genau für solche Situationen soll das System doch da sein.
  • Ich kann nicht verstehen, wie eine verzögerte Warnung akzeptabel sein kann.
    Mich würde interessieren, wie die Kostenabrechnung mit Google am Ende ausgegangen ist.
  • Tatsächlich priorisiert auch AWS so eine Funktion nicht.
    Keine Cloud baut zuerst eine Funktion, die den Geldfluss abschneidet.
  • Die Aussage „für kurzfristigen Gewinn wird langfristiges Vertrauen geopfert“ trifft es genau.
    Das ist ein typisches Bild des Spätkapitalismus.

• Die GitHub-Suchergebnisse zeigen, dass in öffentlichen Repositories oft Gemini-API-Tokens offen herumliegen.
  Google hat API-Keys lange Zeit nicht als Geheimnisse behandelt, und erst bei LLM-Keys wurde plötzlich daraus etwas Vertrauliches.
  Wahrscheinlich hat der Autor den Key im Frontend oder beim Teilen von Code offengelegt.

  • Dieses Problem wurde schon früher gemeldet, und Google hatte angekündigt, geleakte Keys für die Gemini API zu blockieren.
    Das steht sowohl im zugehörigen HN-Thread als auch in der offiziellen Dokumentation.
    Umso fraglicher ist, warum solche Fälle trotzdem wieder auftreten.
  • In den Suchergebnissen sind tatsächlich keine echten Keys zu sehen.
  • Bei geleakten Keys erscheint die Meldung, dass sie sofort ungültig gemacht wurden.
    „Your API key was reported as leaked. Please use another API key.“
    Das heißt, die meisten werden offenbar automatisch blockiert.
  • Die Vorstellung, API-Keys nicht als Geheimnisse zu behandeln, ist absurd.

• In Google Cloud gibt es keine einfache Möglichkeit, ein Hard Cap zu setzen.
  Ich habe selbst über eine Stunde lang nach der Einstellung gesucht und schließlich auf Reddit herausgefunden, dass man Pub/Sub → Cloud Function → Abrechnung deaktivieren verwenden muss.
  Das ist eine komplett wahnsinnige Konstruktion.

  • Ein Test, den ich gerne mache, ist, Gemini-Modelle zu bitten: „Schreibe ein Skript, das die API-Nutzung des Projekts abruft.“
    Die Fehlerquote liegt bei 100 %.
  • Das ist praktisch eine Benutzerfalle (antifeature).
  • Wahrscheinlich ist das Absicht im Design.
    Wenn eine vom Nutzer selbst gebaute Schutzmaßnahme versagt, kann man leichter sagen: „Nicht unsere Verantwortung.“
  • Dass es so eine Funktion nicht gibt, zeigt, dass dem Unternehmen Anreize zum Schutz der Nutzer fehlen.
  • Bei AWS oder Azure ist es genauso.
    Es wäre gut, wenn bei Überschreiten eines Grenzwerts automatisch ein Kill Switch ausgelöst würde.
    Fünf Stunden Downtime wären verkraftbar, eine riesige Rechnung aber nicht.

• Nachdem ich diesen Beitrag gelesen hatte, habe ich sofort meinen Firebase-Tarif herabgestuft.
  Ich war schockiert über einen Fall, in dem in einem Monat $6.909 für APIs berechnet wurden, die die Person gar nicht aufgerufen hatte.
  Ich habe früher auch einmal während einer Schulung einen API-Key erstellt und dachte plötzlich daran, dass ihn vielleicht jemand fotografiert haben könnte.

  • Hat in dieser Sitzung wirklich jemand den Key fotografiert? Mich würde interessieren, was die Ursache war.

• 2020–21 habe ich Studierenden Cloud-Dienste mit dem AWS Free Tier beigebracht.
  Ich hatte einen MediaWiki-Server aufgesetzt, aber es tauchten ständig Spam-Accounts auf und die Sicherheit wirkte unsicher.
  Es fühlte sich an, als würden die Netzwerkports permanent angegriffen.
  Schließlich merkte ich, dass es keine Möglichkeit gab, das Budget auf $20–30 zu begrenzen, und gab AWS auf.
  Die Cloud wirkt zwar bequem in der Verwaltung, ist aber wegen des unbegrenzten Kostenrisikos sowohl für Einzelpersonen als auch für Unternehmen gefährlich.

• Für Solo-Entwickler oder kleine Teams ist die Public Cloud eine beängstigende und unsichere Umgebung.
  Es gibt kaum Sicherungen, und die Kosten können unbegrenzt explodieren.
  Deshalb fließt ein erheblicher Teil der Projektzeit in Kostenüberwachung und Abschaltlogik.
  Früher habe ich einfach einen VPS genutzt, aber heute muss man oft Dienste von Google oder AWS verwenden.
  Immerhin hat GCP den kleinen Vorteil, dass man die Verknüpfung mit dem Abrechnungskonto programmatisch trennen kann.

  • Ich frage mich, was passieren würde, wenn man einfach nicht zahlt.
    In den USA gäbe es wohl rechtliche Probleme, aber in anderen Ländern weiß ich es nicht.

• Solche Abrechnungssysteme sind aus Sicht der Customer Experience (CX) katastrophal gestaltet.
  Die Abrechnung ist ereignisbasiert, sodass sich Nutzungsdaten in Queues sammeln und die Aggregation verzögert wird.
  Warnungen kommen ebenfalls erst nach der Aggregation, sodass bei Verzögerungen der Grenzwert längst massiv überschritten ist.
  Diese Struktur schützt das Unternehmen, aber nicht den Kunden.
  Wenn man wirklich kundenorientiert wäre, dürfte ab dem Moment, in dem das Hard Limit erreicht ist, nichts darüber hinaus berechnet werden.
  Nur dann hätte das Unternehmen einen echten Anreiz, sein eigenes Aggregationssystem zu verbessern.

  • Eigentlich ist das Event-basierte Modell selbst nicht das Problem.
    Mit einem Prepaid-Modell oder Diensten mit Datenlimit, bei denen vorab abgebucht wird, wäre das durchaus machbar.
    Letztlich ist es ein Problem von Googles Geschäftspraxis.

• Laut der offiziellen Google-Cloud-Dokumentation kann man im Notfall die Abrechnung deaktivieren, um weitere Kosten zu stoppen.
  Der offizielle Leitfaden warnt vor dem „Risiko irreversibler Ressourcenverluste“.
  Für Test- oder interne Apps ist das aber eine gute Notbremse.
  Auch das Dokument zu anderen Alternativen und die Dokumentation zu Budget-Benachrichtigungen sind hilfreich.

  • Allerdings kann es zwischen Kostenentstehung und Warnung zu Verzögerungen von mehreren Stunden bis Tagen kommen.
    Ich habe einmal in nur 5 Minuten $400 ausgegeben.

• Wir hatten dasselbe Problem.
  Ein Key, der ursprünglich nicht geheim war, wurde nach Aktivierung der Gemini API plötzlich als geheim behandelt, ohne jede Warnung.
  Zum Glück haben wir es durch eine Benachrichtigung früh entdeckt, sodass der Schaden auf $26.000 begrenzt blieb.
  Wir haben beim Google-Support eine Rückerstattung beantragt, wurden zunächst aber abgewiesen; derzeit wird der Fall erneut geprüft.
  In solchen Fällen sollte man das Thema so weit wie möglich an höhere Stellen eskalieren.