Denegación de cartera: cómo los ataques disparan tu factura de Firebase

Una denegación de servicio intenta tumbar tu app. Una denegación de cartera (denial of wallet) intenta encarecerla: en un backend serverless de pago por uso como Firebase, la infraestructura escala para absorber el tráfico, y pagas cada lectura, invocación y gigabyte que sirve. La app sigue en pie; el daño es la factura.

Ni siquiera hace falta un atacante. Un bug que lee una colección en bucle, o una clave de API de IA filtrada, produce exactamente la misma factura.

• Los clientes hablan directamente con la base de datos. Tu Firestore o Realtime Database es accesible desde cualquier navegador que tenga tu configuración. Las reglas de seguridad deciden qué puede leer; no deciden con qué frecuencia.
• Hasta las respuestas vacías cuestan. Firestore cobra "a minimum charge of one document read for each query that you perform, even if the query returns no results" («un mínimo de una lectura de documento por cada consulta que hagas, aunque la consulta no devuelva resultados»), y las lecturas necesarias para evaluar tus reglas también se facturan (precios de Firestore).
• Los archivos públicos son ancho de banda público. Un archivo popular o rastreado en Cloud Storage o Hosting factura tráfico de salida en cada descarga.
• Las funciones escalan por defecto. Sin un ajuste de instancias máximas, una avalancha de peticiones es una avalancha de instancias.

1. Reglas de seguridad estrictas. Deja que los usuarios lean solo lo que necesitan, y nunca dejes una colección abierta mientras «lo terminas luego».
2. App Check. Ayuda "preventing unauthorized clients from accessing your backend resources" («impidiendo que clientes no autorizados accedan a tus recursos de backend») para Firestore, Realtime Database, Storage, funciones callable y AI Logic. Google reconoce con honestidad que "prevents some, but not all, abuse vectors" («evita algunos vectores de abuso, pero no todos») (App Check).
3. Límites a lo que puede escalar. Las instancias máximas en las funciones y las cuotas de peticiones en las API convierten un coste ilimitado en uno acotado (cómo limitar el gasto de Firebase).
4. Protege las claves de API que cuestan dinero. Restringe las claves por API y por app, y nunca incluyas una clave de IA sin restricciones en un cliente.

La prevención reduce las probabilidades; no las deja en cero. La última línea es darse cuenta rápido y actuar sin una persona de por medio. Las alertas de presupuesto son demasiado lentas para eso (aquí tienes por qué), así que fíjate en el uso: las lecturas, invocaciones y bytes descargados llegan a Cloud Monitoring en minutos.

Eso es lo que hace la detección de picos de uso de FireShield en Pro: compara la última hora de cada servicio vigilado con su hora media de la semana anterior y, si supera el multiplicador que fijes, te avisa, lanza un Soft Kill o, si lo elegiste, desconecta la facturación.