Escáner de reglas de Firebase: detecta reglas abiertas en Firestore, Realtime Database y Storage

Cómo el escáner encuentra reglas abiertas de Firebase

Los servicios de Firebase exponen formas de URL conocidas y predecibles. Un escáner sin credenciales puede sondear cada uno y observar si las lecturas anónimas tienen éxito. La verificación baas.firebase-rules de FixVibe ejecuta tres sondeos independientes — uno por servicio de Firebase:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. El escáner sondea https://[project-id]-default-rtdb.firebaseio.com/.json. Si la raíz se puede leer anónimamente, la respuesta es el árbol completo de la base de datos como JSON. Una prueba más conservadora consulta .json?shallow=true, que devuelve solo las claves de primer nivel — un hallazgo en cualquier caso.
• Cloud Storage. El escáner consulta https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Si la respuesta lista nombres de archivo sin autenticación, el bucket es listable de forma anónima. El storage listable es un hallazgo incluso cuando las descargas de archivos individuales se deniegan — los atacantes enumeran el bucket para encontrar nombres de archivo adivinables.

Cómo se ve realmente el footgun de modo prueba

La documentación de arranque rápido de Firebase incluye uno de los bloques de reglas más copiados de internet:

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

Firebase solía añadir una caducidad automática de 30 días a estas reglas. Eso cambió: hoy las reglas persisten para siempre a menos que el desarrollador las reemplace. Las herramientas de codificación con IA — habiendo entrenado en años de documentación que incluye el bloque de modo prueba — frecuentemente lo emiten textualmente y le dicen al desarrollador "esta es tu regla de seguridad". No lo es.

Otras variantes que aparecen en producción pero son igualmente permisivas:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• Una variante con marca de tiempo futura: una regla que permite todo hasta una fecha lejana en el futuro. Nunca expira efectivamente (consulta el bloque resaltado arriba).
• allow read: if true; allow write: if request.auth != null; — lecturas públicas, cualquier usuario autenticado puede escribir.
• allow read, write: if request.auth != null; — cualquier usuario autenticado puede leer o escribir cualquier documento, incluyendo datos de otros usuarios.

Qué hacer cuando el escáner encuentra una regla abierta

Las reglas abiertas de Firebase son una emergencia en tiempo de ejecución. La corrección tiene la misma forma en los tres servicios: acota cada regla a request.auth.uid contra un campo de propietario explícito. Cada servicio tiene su propia sintaxis de reglas:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. El binding de segmento de ruta {userId} se convierte en el único documento que el usuario puede tocar.

match /users/{userId} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

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

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Convención: guarda los archivos bajo users/[uid]/[filename] y deja que la ruta imponga la propiedad.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Despliega las reglas vía la CLI de Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifica que las nuevas reglas estén en producción re-ejecutando el escaneo de FixVibe — el hallazgo baas.firebase-rules debería desaparecer.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Cómo se compara esto con las herramientas integradas de Firebase

La consola de Firebase muestra las reglas actuales pero no las audita contra el comportamiento en tiempo de ejecución. El simulador de reglas de Firebase te permite probar la lógica de las reglas contra solicitudes sintéticas — útil pero local. Ninguna de las dos herramientas te dice lo que tus reglas de producción realmente devuelven a un atacante anónimo en internet público. Un escáner externo como FixVibe (o Burp Suite con configuración manual) es lo único que sondea desde el mismo ángulo que un atacante. El propio App Check de Google mitiga el abuso pero no sustituye a reglas correctamente acotadas.

Preguntas frecuentes

Próximos pasos

Ejecuta un escaneo gratuito de FixVibe contra tu URL de producción — la verificación baas.firebase-rules está en todos los planes y marca reglas abiertas en Firestore, Realtime Database y Cloud Storage. Para una explicación más profunda del patrón allow read, write: if true específicamente, consulta Firebase allow read, write: if true explicado. Para la vista general en Supabase, Firebase, Clerk y Auth0, lee Escáner de configuraciones erróneas de BaaS.