900 sitios, 125 millones de cuentas, 1 vulnerabilidad
El modelo de seguridad de Firebase y sus trampas
- Muchos consideran que las reglas de seguridad de Firebase son conceptualmente sólidas, pero difíciles de usar correctamente en la práctica, especialmente para Realtime Database.
- Las reglas son de tipo “configurar y olvidar”: los nuevos campos/colecciones a menudo heredan reglas demasiado permisivas cuando cambia la lógica de negocio.
- Los problemas de seguridad surgen de:
- Un modelo novedoso basado en reglas en comparación con los backends tradicionales.
- La facilidad de realizar escaneos masivos cuando muchas apps usan la misma plataforma.
- Valores predeterminados inseguros / patrones de “permitir por defecto” y desarrolladores que simplemente usan
read/write truepara que funcione.
- Crítica a la UX: la mayor parte de Firebase tiene una interfaz pulida, pero las reglas son un simple archivo de configuración que muchos desarrolladores nuevos evitan tocar correctamente.
Soporte de Google y problemas organizativos
- Varios comentarios describen el soporte de Firebase/Google como poco receptivo y fuertemente subcontratado.
- Existe la sensación de que Google invierte poco en soporte humano, de alta especialización, para productos para desarrolladores.
- Algunos sostienen que esta cultura de “primero bots, luego humanos” podría perjudicar a Google a largo plazo; otros creen que la regulación o la simple inercia importan más.
Arquitectura: acceso directo a la base de datos desde el frontend
- A muchos les incomoda que el frontend escriba directamente en una base de datos, incluso con reglas:
- Es más difícil garantizar validación, comprobaciones de contenido y requisitos de privacidad cambiantes.
- Mayor “superficie para olvidar” en comparación con un backend más centralizado.
- Quienes lo defienden dicen que funciona para aplicaciones sencillas de “datos solo del usuario” (p. ej., notas/sincronización) y que los proyectos maduros a menudo trasladan las escrituras a Cloud Functions o a servidores tradicionales, dejando las lecturas en el cliente.
Mitigaciones y buenas prácticas
- Las sugerencias incluyen:
- Modos de seguridad simples basados en plantillas y pruebas obligatorias de reglas.
- Tratar cada colección como si tuviera un perfil de seguridad claro (pública, por usuario, solo administradores) y nunca mezclar sensibilidades.
- Transpiladores de “denegar por defecto” que obliguen a definir reglas explícitas para los campos nuevos.
- Mejores registros de auditoría y notificaciones para cambios implícitos de esquema.
- Mecanismos similares a RLS (como en Postgres/Supabase) para expresar la autenticación en un lenguaje familiar.
Impacto, ética y seguridad de los usuarios
- Muchos sitios vulnerables siguen sin corregirse pese a los intentos de divulgación; los correos suelen ser ignorados y los paneles de control rara vez se revisan.
- Debate sobre publicar una lista de sitios afectados: podría ayudar a los usuarios, pero también a los atacantes.
- Preocupa más ampliamente que las herramientas cloud de baja barrera permitan a organizaciones con poca competencia en seguridad recopilar grandes volúmenes de PII.
- Se aconseja a los usuarios utilizar gestores de contraseñas y correos únicos o alias para limitar los daños de las filtraciones inevitables.