Tu Firebase Filtra Datos (Y No lo Sabes)

Firebase está en todas partes: apps móviles, proyectos side, MVPs de startups… Es cómodo, rápido y "serverless". Pero precisamente por eso, un error sencillo en las reglas puede dejar tus datos abiertos al mundo. Y cuando decimos "abiertos al mundo", lo decimos literalmente: cualquier persona con un navegador puede acceder a tu base de datos sin necesidad de autenticarse.

Estudios recientes han encontrado cientos de apps con millones de descargas que exponían datos sensibles por misconfigurar Firebase: desde mensajes privados hasta tokens de acceso a AWS y GitHub. Y no hace falta ser un APT para explotar esto: basta con saber añadir .json a una URL o llamar a la API REST. En muchos casos, los investigadores que descubrieron estas exposiciones lo hicieron en cuestión de segundos, sin herramientas especializadas ni conocimientos avanzados.

Cómo se Rompe Firebase en la Vida Real

El error más frecuente es dejar la base de datos en "test mode". Cuando creas un proyecto nuevo en Firebase, la consola te ofrece iniciar Realtime Database o Firestore en modo de prueba para que puedas empezar a desarrollar sin complicarte con reglas de seguridad. El problema es que ese modo establece read y write a true para cualquier petición, incluyendo las de usuarios no autenticados. Lo que estaba pensado para las primeras horas de desarrollo se queda semanas o meses en producción sin que nadie se acuerde de cambiarlo.

1rules_version = '2';
2service cloud.firestore {
3match /databases/{database}/documents {
4  match /{document=**} {
5    // ⚠️ PELIGRO: cualquier persona en Internet puede leer y escribir TODO
6    allow read, write: if true;
7  }
8}
9}

El segundo clásico son las reglas demasiado permisivas. Un allow read, write: if true; es el equivalente a dejar la puerta de tu casa abierta con un cartel de bienvenida. También se ven condiciones excesivamente genéricas como allow read: if request.time < timestamp.date(2026, 3, 1), pensadas como "ya lo cambio luego" pero que caducan sin que nadie las revise, quedando abiertas indefinidamente.

Y el tercero: exponer IDs de proyecto y endpoints públicamente sin haber revisado las reglas. El ID de proyecto de Firebase no es un secreto, pero tampoco debería serlo sin protección: aparece en el código fuente de tu aplicación web o móvil y cualquiera puede probarlo.

Los datos que se han encontrado expuestos en investigaciones reales son preocupantes. Datos personales como nombre, email, direcciones y ubicación en tiempo real. Mensajes privados y chats completos. Contraseñas almacenadas en claro —sí, en 2026 sigue pasando—. Detalles de pago, pedidos y facturación. E incluso claves de acceso a otros servicios como AWS, GitHub u OpenAI guardadas "por comodidad" en la base de datos, lo que convierte un problema de Firebase en una brecha de alcance mucho mayor.

Por Qué Esto Pasa Tan a Menudo

La raíz del problema no es que Firebase sea inseguro. Firebase es una plataforma bien diseñada con un modelo de seguridad potente. El problema es que su facilidad de uso juega en su contra cuando se trata de seguridad. El flujo de desarrollo típico es: levantar un proyecto, activar modo de prueba, empezar a construir la app y, cuando todo funciona, desplegar a producción sin revisar las reglas.

Otro factor es que las reglas de seguridad de Firebase no se testean fácilmente de forma automatizada durante el desarrollo. Existen herramientas como el Firebase Emulator Suite y @firebase/rules-unit-testing que permiten escribir tests para las reglas, pero en la práctica muy pocos equipos los implementan. El resultado es que las reglas se configuran una vez y se olvidan.

Cómo Comprobar (Rápido) si tu Firebase Está Abierto

Si ves datos como los de arriba en lugar de {"error":"Permission denied"}, tienes un problema que hay que arreglar hoy, no la semana que viene. Presta atención especial a colecciones que contengan datos de usuarios, como /users, /orders o /messages.

Reglas Mínimas Razonables (No Perfectas, Pero Mucho Mejores)

Firestore

Para apps con usuarios autenticados, las reglas deberían parecerse a algo así:

1rules_version = '2';
2service cloud.firestore {
3match /databases/{database}/documents {
4  // Solo usuarios autenticados acceden a sus propios datos
5  match /users/{userId} {
6    allow read, write: if request.auth != null
7                       && request.auth.uid == userId;
8  }
9
10  // Colecciones públicas de solo lectura
11  match /public/{docId} {
12    allow read: if true;
13    allow write: if false;
14  }
15}
16}

La idea clave es que cada usuario solo pueda leer y escribir sus propios documentos, y que las colecciones públicas sean de solo lectura. A partir de aquí puedes ir afinando —por ejemplo, añadiendo validación de datos en las reglas de escritura o restringiendo el acceso por roles—, pero este patrón básico ya elimina la mayoría de exposiciones graves.

Storage

1rules_version = '2';
2service firebase.storage {
3match /b/{bucket}/o {
4  match /users/{userId}/{allPaths=**} {
5    allow read, write: if request.auth != null
6                       && request.auth.uid == userId;
7  }
8}
9}

De esta forma, cada usuario solo puede leer y escribir ficheros dentro de su propia carpeta. Los ficheros que necesiten ser públicos —como imágenes de producto— deberían ir en una ruta separada con reglas de solo lectura.

Qué Hacer Más Allá de las Reglas

Arreglar las reglas es el paso urgente, pero no te quedes ahí.

Revisa los logs de acceso en Firebase para detectar si alguien ya ha accedido a datos que no debería. Si encuentras patrones sospechosos —lecturas masivas desde IPs desconocidas, accesos a colecciones sensibles sin autenticación—, trata el incidente con la seriedad que merece: podrías estar ante una brecha de datos que requiera notificación bajo GDPR.

Usa Firebase App Check para limitar qué apps pueden hacer peticiones a tu backend. App Check verifica que las peticiones provienen de tu app legítima y no de scripts o clientes modificados, lo que dificulta enormemente el abuso automatizado. No es un sustituto de las reglas de seguridad, pero añade una capa de defensa complementaria que reduce significativamente la superficie de ataque.

Audita los datos que ya están en la base de datos y elimina cualquier información que no debería estar ahí. Claves de acceso a otros servicios, contraseñas en claro, tokens de API… nada de eso debería vivir en Firebase (ni en ninguna base de datos accesible desde el cliente). Usa un gestor de secretos o variables de entorno en Cloud Functions para ese tipo de datos.

Y sobre todo, establece un proceso para que las reglas se revisen cada vez que alguien modifica la estructura de datos o despliega una nueva funcionalidad. Una nueva colección sin reglas específicas hereda las reglas del nivel superior, y si las del nivel superior son demasiado permisivas, acabas de abrir un agujero.

Cómo Ayuda Vulnerabbit

Vulnerabbit detecta automáticamente proyectos Firebase con configuraciones inseguras como parte de su auditoría de infraestructura cloud. Escanea las reglas de Realtime Database, Firestore y Storage, identifica configuraciones demasiado permisivas y te da los pasos exactos para corregirlas, adaptados a tu caso concreto.

Además, el monitoreo continuo te avisa si alguien cambia las reglas de seguridad a una configuración más permisiva, o si se crean nuevas colecciones sin reglas adecuadas. En un equipo donde varios desarrolladores tocan Firebase, este tipo de vigilancia automatizada evita que los errores pasen desapercibidos.

Si tienes un proyecto Firebase en producción y no estás seguro de si las reglas están bien configuradas, este es uno de esos problemas que se arregla en una tarde y que puede ahorrarte un disgusto serio. El coste de no revisarlo es, literalmente, que cualquier persona en Internet pueda descargar tu base de datos completa.