Negação de carteira: como ataques inflam sua fatura do Firebase

Uma negação de serviço tenta derrubar seu app. Uma negação de carteira (denial of wallet) tenta torná-lo caro: em um backend serverless e pago por uso como o Firebase, a infraestrutura escala para absorver o tráfego, e você paga por cada leitura, invocação e gigabyte servido. O app continua no ar; o prejuízo é a fatura.

Nem precisa de um atacante. Um bug que lê uma coleção em loop, ou uma chave de API de IA vazada, gera exatamente a mesma fatura.

• Os clientes falam direto com o banco de dados. Seu Firestore ou Realtime Database pode ser acessado por qualquer navegador que tenha sua configuração. As regras de segurança decidem o que pode ser lido; não decidem com que frequência.
• Até respostas vazias custam. O Firestore cobra "a minimum charge of one document read for each query that you perform, even if the query returns no results" ("no mínimo uma leitura de documento por consulta realizada, mesmo que a consulta não retorne resultados"), e as leituras necessárias para avaliar suas regras também são cobradas (preços do Firestore).
• Arquivos públicos são banda pública. Um arquivo popular ou raspado no Cloud Storage ou no Hosting gera cobrança de tráfego de saída a cada download.
• As funções escalam por padrão. Sem uma configuração de máximo de instâncias, uma enxurrada de requisições é uma enxurrada de instâncias.

1. Regras de segurança rígidas. Deixe os usuários lerem apenas o que precisam e nunca deixe uma coleção aberta enquanto você "termina depois".
2. App Check. Ele ajuda "preventing unauthorized clients from accessing your backend resources" ("impedindo que clientes não autorizados acessem os recursos do seu backend") no Firestore, Realtime Database, Storage, funções callable e AI Logic. O Google admite com honestidade que ele "prevents some, but not all, abuse vectors" ("impede alguns vetores de abuso, mas não todos") (App Check).
3. Limites no que pode escalar. O máximo de instâncias nas funções e as cotas de requisição nas APIs transformam um custo ilimitado em um custo limitado (como limitar os gastos do Firebase).
4. Proteja as chaves de API que custam dinheiro. Restrinja as chaves por API e por app, e nunca publique uma chave de IA sem restrições em um cliente.

A prevenção reduz as chances; não as zera. A última linha de defesa é perceber rápido e agir sem uma pessoa no circuito. Os alertas de orçamento são lentos demais para isso (veja por quê), então observe o uso: leituras, invocações e bytes baixados chegam ao Cloud Monitoring em minutos.

É isso que a detecção de picos de uso do FireShield faz no plano Pro: compara a última hora de cada serviço monitorado com a média por hora da semana anterior e, ao passar do multiplicador que você definir, alerta você, aciona um Soft Kill ou, se você escolheu, desconecta o faturamento.