Denial of Wallet: wie Angriffe Ihre Firebase-Rechnung hochtreiben

Ein Denial of Service versucht, Ihre App lahmzulegen. Ein Denial of Wallet versucht, sie teuer zu machen: Bei einem serverlosen Backend mit nutzungsbasierter Abrechnung wie Firebase skaliert die Infrastruktur, um den Traffic aufzunehmen, und Sie zahlen für jeden Lesevorgang, jeden Aufruf und jedes Gigabyte, das sie ausliefert. Die App bleibt online; der Schaden ist die Rechnung.

Es braucht nicht einmal einen Angreifer. Ein Bug, der eine Collection in einer Schleife liest, oder ein geleakter KI-API-Schlüssel erzeugt genau dieselbe Rechnung.

• Clients sprechen direkt mit der Datenbank. Ihre Firestore- oder Realtime-Database-Instanz ist von jedem Browser erreichbar, der Ihre Konfiguration hat. Security Rules bestimmen, was gelesen werden darf, nicht wie oft.
• Auch leere Antworten kosten. Firestore berechnet "a minimum charge of one document read for each query that you perform, even if the query returns no results" (mindestens einen Dokument-Lesevorgang pro Abfrage, auch wenn sie keine Ergebnisse liefert), und auch Lesevorgänge zur Auswertung Ihrer Regeln werden abgerechnet (Firestore-Preise).
• Öffentliche Dateien sind öffentliche Bandbreite. Eine beliebte oder gescrapte Datei in Cloud Storage oder Hosting verursacht bei jedem Download Egress-Kosten.
• Functions skalieren standardmäßig. Ohne Einstellung für maximale Instanzen ist eine Flut von Anfragen eine Flut von Instanzen.

1. Strenge Security Rules. Lassen Sie Nutzer nur lesen, was sie brauchen, und lassen Sie nie eine Collection offen, während Sie „das später fertig machen“.
2. App Check. Es hilft, indem es "preventing unauthorized clients from accessing your backend resources" (nicht autorisierte Clients am Zugriff auf Ihre Backend-Ressourcen hindert), für Firestore, Realtime Database, Storage, Callable Functions und AI Logic. Google räumt offen ein, dass es "prevents some, but not all, abuse vectors" (einige, aber nicht alle Missbrauchswege verhindert) (App Check).
3. Limits für alles, was skalieren kann. Maximale Instanzen bei Functions und Anfragekontingente bei APIs machen aus unbegrenzten Kosten begrenzte (so begrenzen Sie Firebase-Ausgaben).
4. Schützen Sie API-Schlüssel, die Geld kosten. Beschränken Sie Schlüssel nach API und nach App, und liefern Sie nie einen unbeschränkten KI-Schlüssel in einem Client aus.

Vorbeugung senkt die Wahrscheinlichkeit, auf null bringt sie sie nicht. Die letzte Verteidigungslinie ist, schnell zu bemerken und ohne Menschen zu handeln. Budgetwarnungen sind dafür zu langsam (hier ist der Grund), also schauen Sie auf die Nutzung: Lesevorgänge, Aufrufe und heruntergeladene Bytes erreichen Cloud Monitoring in Minuten.

Genau das macht die Spitzenerkennung von FireShield bei Pro: Sie vergleicht die letzte Stunde jedes überwachten Dienstes mit seiner durchschnittlichen Stunde der vergangenen Woche und benachrichtigt Sie jenseits des von Ihnen festgelegten Multiplikators, löst einen Soft Kill aus oder trennt, wenn Sie das gewählt haben, die Abrechnung.