Escáner de regras de Firebase: atopa regras abertas de Firestore, Realtime Database e Storage

Como o escáner atopa regras abertas de Firebase

Os servizos de Firebase expoñen formas de URL coñecidas e predicibles. Un escáner sen credenciais pode sondear cada unha e observar se as lecturas anónimas teñen éxito. A comprobación baas.firebase-rules de FixVibe execútase en tres sondaxes independentes — unha por servizo 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. O escáner sondea https://[project-id]-default-rtdb.firebaseio.com/.json. Se a raíz é legible anonimamente, a resposta é toda a árbore da base de datos como JSON. Unha proba máis conservadora consulta .json?shallow=true, que devolve só as claves de nivel superior — un achado en calquera caso.
• Cloud Storage. O escáner consulta https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Se a resposta lista nomes de ficheiros sen autenticación, o bucket é listable anonimamente. O almacenamento listable é un achado mesmo cando se denegan as descargas de ficheiros individuais — os atacantes enumeran o bucket para atopar nomes de ficheiro adivinables.

Como é realmente a trampa do modo de proba

A documentación de inicio rápido de Firebase inclúe un dos bloques de regras máis copiados de internet:

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

Firebase adoitaba engadir unha expiración automática de 30 días a estas regras. Iso cambiou: hoxe as regras persisten para sempre a menos que o desenvolvedor as substitúa. As ferramentas de codificación con IA — adestradas en anos de documentación que inclúe o bloque do modo de proba — emítenas con frecuencia textualmente e dinlle ao desenvolvedor "esta é a túa regra de seguranza". Non o é.

Outras variantes que aparecen en produció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;

• Unha variante con marca de tempo futura: unha regra que permite todo ata unha data afastada no futuro. Nunca expira efectivamente (mira o bloque resaltado de arriba).
• allow read: if true; allow write: if request.auth != null; — lecturas públicas, calquera usuario autenticado pode escribir.
• allow read, write: if request.auth != null; — calquera usuario rexistrado pode ler ou escribir calquera documento, incluídos os datos doutros usuarios.

Que facer cando o escáner atopa unha regra aberta

As regras abertas de Firebase son unha emerxencia en tempo de execución. A solución ten a mesma forma nos tres servizos: limita cada regra a request.auth.uid contra un campo de propietario explícito. Cada servizo ten a súa propia sintaxe de regras:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. A ligadura do segmento de camiño {userId} convértese no único documento que o usuario pode 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: almacena ficheiros baixo users/[uid]/[filename] e deixa que o camiño impoña a propiedade.

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

Desprega as regras vía a CLI de Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifica que as novas regras están en produción reexecutando o escaneo de FixVibe — o achado baas.firebase-rules debería desaparecer.

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

Como se compara isto coas ferramentas integradas de Firebase

A Consola de Firebase amósache as regras actuais pero non as audita contra o comportamento en tempo de execución. O simulador de regras de Firebase permíteche probar a lóxica de regras contra solicitudes sintéticas — útil pero local. Ningunha das dúas ferramentas che di o que as túas regras de produción devolven realmente a un atacante anónimo en internet pública. Un escáner externo como FixVibe (ou Burp Suite con configuración manual) é o único que sondea desde o mesmo ángulo que un atacante. O propio App Check de Google mitiga o abuso pero non substitúe regras correctamente acoutadas.

Preguntas frecuentes

Próximos pasos

Executa un escaneo gratuíto de FixVibe contra o teu URL de produción — a comprobación baas.firebase-rules está incluída en todos os plans e sinala regras abertas en Firestore, Realtime Database e Cloud Storage. Para unha explicación máis profunda específica do patrón allow read, write: if true, mira O Firebase allow read, write: if true explicado. Para a visión global de Supabase, Firebase, Clerk e Auth0, le Escáner de configuración incorrecta de BaaS.