Seguridad en Firebase: Los 7 Errores de Configuración que Vemos en Cada Auditoría

Firebase hace que construir aplicaciones sea increíblemente fácil. Autenticación en cinco minutos. Base de datos en tiempo real sin escribir una sola línea de backend. Hosting con un comando. Storage para ficheros con reglas declarativas. Funciones serverless que escalan solas.

El problema es que esa misma facilidad hace que sea increíblemente fácil dejar tu base de datos abierta al mundo entero.

Hemos auditado decenas de proyectos Firebase — desde startups en fase early stage hasta productos en producción con miles de usuarios. Estos 7 errores de configuración aparecen en prácticamente todas las auditorías. No son vulnerabilidades exóticas. Son configuraciones por defecto que nadie cambió, reglas que se escribieron durante el desarrollo y nunca se actualizaron, o simplemente cosas que nadie sabía que había que configurar.

Si usas Firebase, repasa esta lista. La probabilidad de que al menos dos de estos errores estén en tu proyecto es alta.

---

Error 1: Reglas de Realtime Database abiertas en producción

Este es el clásico. Cuando creas un proyecto Firebase y eliges "modo test" para Realtime Database, las reglas quedan así:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Esto significa que cualquier persona con la URL de tu base de datos puede leer y escribir todos los datos. Sin autenticación. Sin restricciones. Todo. Los datos de tus usuarios, sus emails, sus direcciones, su historial de compras. Todo accesible añadiendo .json al final de la URL de tu base de datos.

Firebase muestra un aviso en la consola cuando tus reglas son inseguras. Lo muestra en rojo. Pero la consola tiene tantos avisos que mucha gente lo ignora. O piensa "ya lo cambiaré cuando lance" y se olvida.

Cómo corregirlo

Las reglas de producción deben requerir autenticación como mínimo, y en la mayoría de casos, restringir el acceso a los datos propios del usuario:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cada nodo de tu base de datos debe tener reglas explícitas. Si un nodo no tiene reglas definidas, hereda las del nodo padre. Esto significa que un solo ".read": true en la raíz anula cualquier regla más restrictiva que hayas definido debajo.

---

Error 2: Reglas de Firestore que permiten leer todos los documentos a usuarios autenticados

Este error es más sutil que el anterior. Las reglas no están completamente abiertas — requieren autenticación. Pero cualquier usuario autenticado puede leer todos los documentos de todas las colecciones.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

"Requiere autenticación" suena seguro, hasta que piensas que cualquiera puede crear una cuenta en tu aplicación (a menos que hayas deshabilitado el registro abierto, que es el Error 6). Un atacante crea una cuenta con un email desechable, obtiene un token de autenticación y accede a todos los datos de todos los demás usuarios.

Cómo corregirlo

Las reglas de Firestore deben seguir el principio de mínimo privilegio. Cada colección necesita reglas específicas que limiten el acceso a los datos propios del usuario:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /orders/{orderId} {
      allow read: if request.auth != null && resource.data.userId == request.auth.uid;
      allow create: if request.auth != null && request.resource.data.userId == request.auth.uid;
    }
  }
}

Además, valida los datos de entrada con request.resource.data para asegurar que los campos obligatorios existen y tienen el tipo correcto. Las reglas de Firestore son tu última línea de defensa — no confíes solo en la validación del frontend.

---

Error 3: Reglas de Cloud Storage que permiten subidas públicas

Cloud Storage de Firebase usa un sistema de reglas similar a Firestore. Y el modo test es igual de permisivo:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write;
    }
  }
}

Cualquiera puede subir archivos a tu bucket. Sin límite de tamaño. Sin validación de tipo. Sin autenticación. Esto es un vector de ataque doble: primero, tu bucket se convierte en almacenamiento gratuito para malware o contenido ilegal. Segundo, si tu aplicación muestra archivos del bucket sin validación, un atacante puede subir un fichero HTML malicioso y ejecutar ataques XSS contra tus usuarios.

El coste también escala: si alguien sube terabytes de datos a tu bucket, pagas tú.

Cómo corregirlo

Las reglas deben requerir autenticación, limitar las rutas donde cada usuario puede escribir y validar el tipo y tamaño del archivo:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read: if request.auth != null;
      allow write: if request.auth != null
                   && request.auth.uid == userId
                   && request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Este ejemplo permite que cada usuario solo suba imágenes de menos de 5 MB a su propia carpeta. Ajusta según tu caso, pero el principio es el mismo: autenticación, scoping por usuario, validación de tipo y tamaño.

---

Error 4: API keys expuestas sin App Check

Las API keys de Firebase aparecen en el código frontend. Es así por diseño — Firebase las necesita para inicializar el SDK en el cliente. Google las diseñó como identificadores del proyecto, no como secretos de autenticación.

El problema es que sin una capa adicional de protección, cualquiera puede tomar esa API key y usarla para interactuar con tu proyecto desde un script, un bot o cualquier herramienta que no sea tu aplicación legítima. Puede crear cuentas masivamente, escribir datos basura en tu base de datos o consumir tu cuota de lecturas hasta que tu factura se dispare.

La API key por sí sola no es una vulnerabilidad. Pero sin restricciones, es una puerta abierta.

Cómo corregirlo

Paso 1: Habilita App Check. App Check verifica que las peticiones a tu backend Firebase provienen de tu aplicación legítima (verificada por reCAPTCHA Enterprise en web, DeviceCheck en iOS, Play Integrity en Android). Las peticiones que no superen la verificación son rechazadas.

Paso 2: Restringe la API key en Google Cloud Console. Ve a APIs & Services > Credentials, selecciona tu API key y restringe los referrers HTTP (para web) o los paquetes de aplicación (para móvil). Así, aunque alguien copie la key, no puede usarla desde un dominio o app diferente.

Paso 3: Nunca pongas otras claves sensibles en el frontend. La API key de Firebase es pública por diseño. Pero las claves de servicios como Stripe, SendGrid, o APIs de terceros nunca deben estar en el código del cliente. Usa Firebase Cloud Functions como proxy.

---

Error 5: App Check no habilitado — bots y scripts acceden directamente

Este error está relacionado con el anterior, pero merece su propia sección porque el impacto es diferente. Sin App Check, no solo la API key es utilizable desde fuera de tu app — es que no hay ninguna verificación de que las peticiones provienen de un cliente legítimo.

Esto permite:

• Scraping masivo de datos públicos de tu base de datos
• Abuso de Cloud Functions: si tienes funciones que envían emails, procesan pagos o generan contenido, un bot puede llamarlas en bucle
• Creación masiva de cuentas automatizada
• Agotamiento de cuotas de Firestore, Storage o Realtime Database, inflando tu factura

Hemos visto proyectos Firebase con facturas de miles de euros porque un bot descubrió una Cloud Function sin protección y la llamó millones de veces.

Cómo corregirlo

Activa App Check en Firebase Console > App Check. Configura un proveedor de atestación para cada plataforma (reCAPTCHA Enterprise para web, DeviceCheck para iOS, Play Integrity para Android). Después, activa la protección (enforcement) para cada producto de Firebase que uses: Firestore, Realtime Database, Storage y Cloud Functions.

La activación tiene dos fases: monitorización (que registra pero no bloquea) y enforcement (que bloquea). Empieza con monitorización para asegurarte de que tus clientes legítimos pasan la verificación, y después activa enforcement.

---

Error 6: Autenticación sin verificación de email

Firebase Authentication permite crear cuentas con email y contraseña de forma muy sencilla. Tan sencilla que muchos desarrolladores no se dan cuenta de que, por defecto, la cuenta se crea sin verificar que el email realmente pertenece al usuario.

Esto significa que alguien puede crear una cuenta con [email protected] y acceder a cualquier dato o funcionalidad que tu aplicación asocie a ese email. Si tus reglas de Firestore usan el email (en lugar del UID) para determinar permisos, tienes un problema grave.

Además, sin verificación, tu aplicación se llena de cuentas creadas con emails desechables (Guerrilla Mail, Temp Mail, Mailinator). Si envías notificaciones por email, tu tasa de rebote sube, tu reputación de remitente baja y eventualmente tus emails legítimos acaban en spam.

Cómo corregirlo

Opción 1: Verifica el email antes de dar acceso. Después de crear la cuenta, envía un email de verificación con sendEmailVerification(). En tus reglas de Firestore, comprueba request.auth.token.email_verified == true antes de permitir el acceso.

allow read, write: if request.auth != null
                   && request.auth.token.email_verified == true;

Opción 2: Bloquea dominios desechables. Firebase permite configurar una lista negra de dominios de email en Authentication > Settings > Authorized domains. No es infalible (hay miles de dominios desechables), pero reduce el ruido.

Opción 3: Usa proveedores OAuth. Si tu caso de uso lo permite, ofrece solo Google Sign-In, Apple Sign-In o Microsoft. Estos proveedores ya verifican la identidad del usuario y eliminan el problema de emails falsos.

---

Error 7: Cloud Functions con cuentas de servicio sobredimensionadas

Cuando despliegas una Cloud Function, por defecto se ejecuta con la cuenta de servicio predeterminada de App Engine ([email protected]). Esta cuenta, en muchos proyectos, tiene el rol de Editor a nivel de proyecto.

El rol de Editor permite leer y modificar prácticamente todos los recursos del proyecto de Google Cloud: bases de datos, buckets de almacenamiento, instancias de Compute Engine, secretos de Secret Manager y mucho más. Si un atacante encuentra una vulnerabilidad en tu Cloud Function (una inyección de comandos, una dependencia comprometida, un SSRF), hereda esos permisos.

En la práctica, esto convierte cualquier vulnerabilidad en una Cloud Function en un acceso total al proyecto.

Cómo corregirlo

Crea cuentas de servicio específicas para cada función (o grupo de funciones) con solo los permisos que necesitan. Una función que lee datos de Firestore solo necesita el rol roles/datastore.viewer. Una función que sube archivos a Storage solo necesita roles/storage.objectCreator.

En Firebase, puedes especificar la cuenta de servicio al desplegar:

export const myFunction = functions
  .runWith({ serviceAccount: '[email protected]' })
  .https.onCall(async (data, context) => {
    // ...
  });

Revisa los permisos de tu cuenta de servicio predeterminada. Si tiene el rol de Editor, cámbialo. Es el cambio con mayor impacto en seguridad que puedes hacer en tu proyecto Firebase en menos de diez minutos.

---

Cómo auditar tu proyecto Firebase

Puedes revisar estos 7 puntos manualmente. No es difícil — solo requiere saber dónde mirar.

Revisión manual

1. Reglas de seguridad: ve a Firebase Console > Realtime Database/Firestore/Storage > Rules. Lee las reglas línea por línea. Busca true, null o condiciones que solo comprueban auth != null sin validar el UID.
2. App Check: Firebase Console > App Check. Comprueba si está habilitado y en modo enforcement para cada producto.
3. Autenticación: Firebase Console > Authentication > Settings. Revisa si la verificación de email está habilitada. Comprueba los métodos de autenticación activos.
4. Cloud Functions: revisa el código de cada función. Comprueba qué cuenta de servicio usa y qué permisos tiene. Ve a Google Cloud Console > IAM para ver los roles asignados.
5. API key restrictions: Google Cloud Console > APIs & Services > Credentials. Revisa si tu API key tiene restricciones de referrer o paquete.

Auditoría automatizada con CSPM

La revisión manual funciona, pero no escala. Si tienes múltiples proyectos Firebase, si el equipo hace cambios frecuentes o si simplemente quieres asegurarte de que no se te escapa nada, necesitas una herramienta que audite automáticamente la configuración de forma continua.

Esto es lo que hace un CSPM (Cloud Security Posture Management). Conectas tu proyecto y la herramienta audita reglas de seguridad, permisos de Storage, configuración de autenticación, roles IAM de Cloud Functions y restricciones de API keys. Cuando algo cambia y deja de cumplir las mejores prácticas, recibes una alerta.

Vulnerabbit incluye un módulo específico para seguridad en Firebase que cubre exactamente estos 7 puntos y más. Analiza las reglas de Realtime Database, Firestore y Storage, verifica la configuración de App Check y Authentication, y audita los permisos de las cuentas de servicio de Cloud Functions.

---

Una nota sobre la cultura "move fast and break things"

Firebase es el producto favorito de los equipos que priorizan velocidad. Y tiene sentido: permite construir un MVP funcional en días. Pero la velocidad tiene un coste cuando la seguridad se deja para "después".

El problema es que "después" normalmente llega cuando ya tienes usuarios reales, datos reales y un incidente real. Hemos visto startups que descubrieron sus reglas abiertas cuando un usuario les avisó de que podía ver los datos de otros usuarios. O cuando recibieron una factura de Google Cloud diez veces mayor de lo esperado porque un bot estaba abusando de sus Cloud Functions.

La buena noticia es que corregir estos 7 errores no requiere una reescritura de la aplicación. Son cambios de configuración que puedes hacer en una tarde. Y el impacto en la seguridad de tu proyecto es enorme.

Si no estás seguro de por dónde empezar, haz el escáner gratuito de Vulnerabbit sobre tu dominio. Te dará una primera visión de tu superficie de ataque externa. Desde ahí, puedes profundizar en la configuración de Firebase con nuestro módulo de seguridad Firebase.

También puedes leer nuestro artículo sobre por qué Firebase es inseguro por defecto, donde explicamos en detalle el modelo de seguridad de Firebase y por qué genera tantos problemas.

---

Conclusión

Firebase no es inseguro. Es inseguro por defecto. La diferencia es importante. Las herramientas están ahí: reglas de seguridad, App Check, verificación de email, cuentas de servicio personalizadas. Pero Google no las activa por ti, porque activarlas añade fricción al desarrollo. Y Firebase está diseñado para minimizar la fricción.

La responsabilidad de la seguridad es tuya. Estos 7 errores no son bugs ni vulnerabilidades de la plataforma. Son decisiones de configuración que alguien tiene que tomar. Si nadie las toma, las reglas por defecto ganan. Y las reglas por defecto están diseñadas para que todo funcione, no para que todo sea seguro.

Revisa tu proyecto hoy. Empieza por las reglas de seguridad. Es el cambio más fácil y con mayor impacto que puedes hacer.