¿Tu base de datos Firestore es pública? Probablemente sí.

Audita tus reglas de seguridad en Firestore, Realtime Database y Storage en minutos. Detecta permisos 'wildcard' (allow write: if true), usuarios anónimos y funciones expuestas antes de que filtres datos.

Análisis de Reglas

No solo buscamos errores de sintaxis. Analizamos la lógica de tus archivos firestore.rules y storage.rules para encontrar permisos excesivos que exponen datos PII.

Auth Hardening

¿Tienes habilitado el 'Sign-in Anónimo' sin restricciones? Verificamos tu configuración de Firebase Authentication para asegurar que solo usuarios legítimos accedan.

Cloud Functions

Auditamos los permisos IAM de tus Cloud Functions. Detecta si una función interna es invocable públicamente (allUsers) por error.

EL PROBLEMA NOSQL

Los escáneres tradicionales no entienden Firebase.

Dejaste `allow read, write: if true;` para probar algo rápido y olvidaste cerrarlo. Un escáner tradicional busca SQL Injection, no errores de lógica en reglas NoSQL. Nosotros sí.

i deploying firestore:rules...


firestore:rules: rules deployed successfully

🐰 Vulnerabbit CI/CD Check:
[FAIL] Regla Insegura Detectada

File: firestore.rules:12
match /users/{userId} { allow read, write: if true; }

-> Riesgo: Cualquiera puede borrar todos los usuarios.
[WARN] Cloud Function Pública-> Function: deleteUserData tiene permiso allUsers.
BLOCKING DEPLOYMENT due to critical security issues.
COBERTURA NATIVA

Vulnerabbit vs. El Resto

La mayoría de herramientas de seguridad ignoran Firebase o lo tratan como un servidor web genérico. Nosotros entendemos tu stack.

VulnerabbitEscáneres Tradicionales
Firestore Rules✅ Análisis Lógico Profundo❌ Ciegos (No soportado)
Realtime DB✅ Detección de Instancias Shadow❌ Ciegos
Contexto✅ Entiende Apps Móviles/SPA❓ Solo ve servidores web
CostoIncluido en planes estándarN/A (No lo cubren)
COBERTURA COMPLETA

Qué Analizamos en Cada Proyecto Firebase

Nuestro escáner conecta vía Service Account de solo lectura y evalúa cada capa de tu proyecto Firebase contra más de 50 controles de seguridad específicos para el ecosistema NoSQL y serverless de Google.

Firestore y Realtime Database

  • Reglas permisivas: Detectamos patrones como allow read, write: if true y variantes menos obvias que otorgan acceso universal a colecciones sensibles.
  • Validación de datos ausente: Reglas que permiten escritura sin validar el tipo, tamaño o estructura de los datos, abriendo la puerta a inyección de contenido malicioso.
  • Shadow Shards: Instancias de Realtime Database secundarias creadas durante desarrollo que siguen activas con reglas por defecto abiertas.
  • Escalado de privilegios: Reglas donde un usuario autenticado puede modificar documentos de otros usuarios manipulando el path del recurso.

Authentication, Storage y Functions

  • Sign-in Anónimo sin restricciones: Si habilitaste autenticación anónima para prototipado y no la limitaste, cualquier persona puede crear sesiones y acceder a datos protegidos solo por request.auth != null.
  • Storage Rules: Buckets de Cloud Storage con reglas que permiten lectura o escritura pública. Detectamos archivos sensibles (backups, exports CSV) accesibles sin autenticación.
  • Cloud Functions públicas: Funciones con binding allUsers que permiten invocación sin autenticación, potencialmente exponiendo lógica interna o datos sensibles.
  • Permisos IAM excesivos: Service accounts de Cloud Functions con roles de Editor o Owner en lugar de permisos mínimos necesarios.
PATRONES DE RIESGO

Errores Comunes en Proyectos Firebase

Estos son los patrones de configuración insegura que encontramos con mayor frecuencia en auditorías de proyectos reales. Todos son evitables con las reglas correctas.

El "if true" Olvidado

El escenario más común: durante desarrollo, el equipo abre las reglas para evitar fricciones. La app llega a producción y nadie recuerda restringirlas. Un atacante puede leer y borrar toda tu base de datos con una simple petición HTTP.

Auth != Autorización

Muchos desarrolladores confunden autenticación con autorización. Escriben request.auth != null pensando que es suficiente, pero cualquier usuario autenticado (incluidos anónimos) puede acceder a datos de otros usuarios si no se valida el ownership del documento.

API Keys en el Frontend

Las API keys de Firebase son públicas por diseño, pero si no están correctamente restringidas por dominio y servicio, un atacante puede usarlas desde cualquier origen para abusar de tus cuotas de Authentication, consumir recursos de Cloud Functions o enviar notificaciones push no autorizadas.

Vulnerabbit detecta estos patrones automáticamente en cada escaneo y genera la regla corregida lista para desplegar. Además, si integras el escaneo en tu pipeline CI/CD, puedes bloquear cualquier despliegue de reglas que contenga patrones inseguros antes de que llegue a producción. De esta forma, la seguridad se convierte en parte del flujo de desarrollo en lugar de ser una auditoría reactiva.

Cierra la puerta trasera de tu app hoy.

No necesitas ser experto en seguridad para arreglar tus reglas. Conecta tu proyecto con una Service Account de lectura.

Lectura exclusiva (Read-Only). No modificamos tu configuración.

Preguntas Frecuentes

Todo lo que necesitas saber sobre Vulnerabbit Burrow

¿Necesito instalar un SDK?+
No. Nos conectamos vía Service Account con permisos de lectura. No modificamos tu código ni requerimos instalar agentes en tu app.
¿Soportan Realtime Database?+
Sí. Escaneamos tanto Firestore como Realtime Database para detectar instancias abiertas o 'shadow shards' olvidados.
¿Cómo se compara con AWS Security Hub?+
AWS Security Hub no ve Firebase ni entiende las reglas de seguridad de Firestore. Nosotros somos nativos para el stack de Firebase.
¿Es seguro?+
Sí. Solo requerimos permisos de lectura y análisis de configuración. Tus datos de usuario permanecen en tu proyecto.

¿Listo para tomar el control?

Únete a las empresas que ya aseguran su futuro con Vulnerabbit.

Protege tu empresa gratis — 14 días
Analizar mis Reglas Gratis