Denial of wallet: come gli attacchi gonfiano la tua fattura Firebase

Un denial of service cerca di mettere giù la tua app. Un denial of wallet cerca di renderla costosa: su un backend serverless a consumo come Firebase, l'infrastruttura scala per assorbire il traffico, e tu paghi ogni lettura, invocazione e gigabyte servito. L'app resta online; il danno è la fattura.

Non serve nemmeno un attaccante. Un bug che legge una collezione in un ciclo, o una chiave API di IA trapelata, produce esattamente la stessa fattura.

• I client parlano direttamente con il database. Il tuo Firestore o Realtime Database è raggiungibile da qualsiasi browser che abbia la tua configurazione. Le regole di sicurezza decidono cosa può leggere; non decidono quanto spesso.
• Anche le risposte vuote costano. Firestore addebita "a minimum charge of one document read for each query that you perform, even if the query returns no results" (cioè, «un minimo di una lettura di documento per ogni query eseguita, anche se la query non restituisce risultati»), e vengono fatturate anche le letture necessarie per valutare le tue regole (prezzi di Firestore).
• File pubblici significano banda pubblica. Un file popolare o oggetto di scraping in Cloud Storage o Hosting fattura il traffico in uscita a ogni download.
• Le funzioni scalano per impostazione predefinita. Senza un'impostazione di istanze massime, un'ondata di richieste è un'ondata di istanze.

1. Regole di sicurezza rigorose. Lascia che gli utenti leggano solo ciò che serve loro, e non lasciare mai una collezione aperta mentre «la finisci dopo».
2. App Check. Aiuta "preventing unauthorized clients from accessing your backend resources" (cioè, «impedendo ai client non autorizzati di accedere alle risorse del tuo backend») per Firestore, Realtime Database, Storage, funzioni callable e AI Logic. Google ammette onestamente che "prevents some, but not all, abuse vectors" (cioè, «previene alcuni vettori di abuso, ma non tutti») (App Check).
3. Limiti su ciò che può scalare. Le istanze massime sulle funzioni e le quote di richieste sulle API trasformano un costo illimitato in uno limitato (come limitare la spesa di Firebase).
4. Proteggi le chiavi API che costano denaro. Limita le chiavi per API e per app, e non distribuire mai una chiave di IA senza restrizioni in un client.

La prevenzione riduce le probabilità; non le azzera. L'ultima linea di difesa è accorgersene in fretta e agire senza un essere umano di mezzo. Gli avvisi di budget sono troppo lenti per questo (ecco perché), quindi guarda invece l'utilizzo: letture, invocazioni e byte scaricati arrivano a Cloud Monitoring in pochi minuti.

È ciò che fa il rilevamento dei picchi di utilizzo di FireShield su Pro: confronta l'ultima ora di ogni servizio monitorato con la sua ora media della settimana precedente e, oltre il moltiplicatore che imposti, ti avvisa, attiva un Soft Kill o, se lo hai scelto, scollega la fatturazione.