Déni de portefeuille : comment des attaques font grimper votre facture Firebase

Un déni de service cherche à faire tomber votre application. Un déni de portefeuille cherche à la rendre coûteuse : sur un backend serverless facturé à l'usage comme Firebase, l'infrastructure s'adapte pour absorber le trafic, et vous payez chaque lecture, chaque invocation et chaque gigaoctet servi. L'application reste en ligne ; c'est la facture qui encaisse les dégâts.

Il n'y a même pas besoin d'un attaquant. Un bug qui lit une collection en boucle, ou une clé d'API d'IA divulguée, produit exactement la même facture.

• Les clients parlent directement à la base de données. Votre Firestore ou votre Realtime Database est accessible depuis n'importe quel navigateur disposant de votre configuration. Les règles de sécurité décident de ce qu'il peut lire, pas de la fréquence.
• Même les réponses vides coûtent. Firestore facture "a minimum charge of one document read for each query that you perform, even if the query returns no results" (« au minimum une lecture de document pour chaque requête effectuée, même si elle ne renvoie aucun résultat »), et les lectures nécessaires à l'évaluation de vos règles sont aussi facturées (tarifs Firestore).
• Des fichiers publics, c'est de la bande passante publique. Un fichier populaire ou aspiré dans Cloud Storage ou Hosting facture le trafic sortant à chaque téléchargement.
• Les fonctions montent en charge par défaut. Sans réglage d'instances maximales, un afflux de requêtes devient un afflux d'instances.

1. Des règles de sécurité strictes. Ne laissez les utilisateurs lire que ce dont ils ont besoin, et ne laissez jamais une collection ouverte en vous disant que vous « finirez plus tard ».
2. App Check. Il aide en "preventing unauthorized clients from accessing your backend resources" (« empêchant les clients non autorisés d'accéder à vos ressources backend ») pour Firestore, Realtime Database, Storage, les fonctions callable et AI Logic. Google reconnaît honnêtement qu'il "prevents some, but not all, abuse vectors" (« bloque certains vecteurs d'abus, mais pas tous ») (App Check).
3. Des limites sur ce qui peut monter en charge. Les instances maximales sur les fonctions et les quotas de requêtes sur les API transforment un coût illimité en coût borné (comment limiter les dépenses Firebase).
4. Protéger les clés d'API qui coûtent de l'argent. Restreignez les clés par API et par application, et ne livrez jamais une clé d'IA non restreinte dans un client.

La prévention réduit les risques, elle ne les annule pas. La dernière ligne de défense consiste à s'en apercevoir vite et à agir sans intervention humaine. Les alertes budgétaires sont trop lentes pour cela (voici pourquoi) ; regardez plutôt l'utilisation : lectures, invocations et octets téléchargés arrivent dans Cloud Monitoring en quelques minutes.

C'est ce que fait la détection de pics d'utilisation de FireShield sur la formule Pro : elle compare la dernière heure de chaque service surveillé à son heure moyenne de la semaine précédente et, au-delà du multiplicateur que vous fixez, vous alerte, déclenche un Soft Kill ou, si vous l'avez choisi, dissocie la facturation.