Escàner de regles de Firebase: troba regles obertes a Firestore, Realtime Database i Storage

Com troba l'escàner les regles obertes de Firebase

Els serveis de Firebase exposen formes d'URL conegudes i predictibles. Un escàner sense credencials pot sondejar cadascuna i observar si les lectures anònimes tenen èxit. La comprovació baas.firebase-rules de FixVibe s'executa en tres sondejos independents — un per servei 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. L'escàner sondeja https://[project-id]-default-rtdb.firebaseio.com/.json. Si l'arrel es pot llegir anònimament, la resposta és tot l'arbre de la base de dades com a JSON. Una prova més conservadora consulta .json?shallow=true, que retorna només les claus de nivell superior — una troballa de tota manera.
• Cloud Storage. L'escàner consulta https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Si la resposta llista noms de fitxer sense autenticació, el contenidor és llistat anònimament. L'emmagatzematge llistat és una troballa fins i tot quan les descàrregues individuals de fitxers estan denegades — els atacants enumeren el contenidor per trobar noms de fitxer endevinables.

Quin aspecte té realment el parany del mode test

La documentació de quickstart de Firebase inclou un dels blocs de regles més copiats d'internet:

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

Firebase abans afegia una caducitat automàtica de 30 dies a aquestes regles. Això ha canviat: avui les regles persisteixen per sempre tret que el desenvolupador les substitueixi. Les eines de codificació amb IA — havent-se entrenat amb anys de documentació que inclou el bloc de mode test — sovint l'emeten literalment i diuen al desenvolupador "aquesta és la teva regla de seguretat". No ho és.

Altres variants que apareixen en producció però són igual de permissives:

// 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 variant amb marca temporal futura: una regla que permet tot fins a una data llunyana al futur. Mai expira efectivament (mira el bloc ressaltat a sobre).
• allow read: if true; allow write: if request.auth != null; — lectures públiques, qualsevol usuari autenticat pot escriure.
• allow read, write: if request.auth != null; — qualsevol usuari amb sessió iniciada pot llegir o escriure qualsevol document, incloses les dades d'altres usuaris.

Què fer quan l'escàner troba una regla oberta

Les regles obertes de Firebase són una emergència en temps d'execució. La correcció té la mateixa forma als tres serveis: delimita cada regla a request.auth.uid contra un camp de propietari explícit. Cada servei té la seva pròpia sintaxi de regles:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. L'enllaç del segment de ruta {userId} es converteix en l'únic document que l'usuari pot 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ó: emmagatzema els fitxers sota users/[uid]/[filename] i deixa que la ruta forci la propietat.

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

Desplega les regles via la CLI de Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifica que les noves regles són en producció tornant a executar l'escaneig de FixVibe — la troballa baas.firebase-rules hauria de desaparèixer.

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

Com es compara això amb les eines integrades de Firebase

La consola de Firebase et mostra les regles actuals però no les audita contra el comportament en temps d'execució. El simulador de regles de Firebase et permet provar la lògica de les regles contra peticions sintètiques — útil però local. Cap d'aquestes eines et diu què retornen realment les teves regles de producció a un atacant anònim a internet pública. Un escàner extern com FixVibe (o Burp Suite amb configuració manual) és l'única cosa que sondeja des del mateix angle que ho faria un atacant. El propi App Check de Google mitiga l'abús però no substitueix unes regles correctament delimitades.

Preguntes freqüents

Següents passos

Executa un escaneig gratuït de FixVibe contra el teu URL de producció — la comprovació baas.firebase-rules s'inclou a tots els plans i marca regles obertes a Firestore, Realtime Database i Cloud Storage. Per a una explicació més profunda del patró allow read, write: if true en concret, consulta Firebase allow read, write: if true explicat. Per a la vista general entre Supabase, Firebase, Clerk i Auth0, llegeix Escàner de configuracions errònies de BaaS.