Scaner de reguli Firebase: găsește reguli Firestore, Realtime Database și Storage deschise

Cum găsește scanerul reguli Firebase deschise

Serviciile Firebase expun forme de URL bine cunoscute și previzibile. Un scaner fără credențiale poate sonda fiecare și observa dacă citirile anonime reușesc. Verificarea baas.firebase-rules a FixVibe rulează în trei sonde independente — una per serviciu 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. Scanerul sondează https://[project-id]-default-rtdb.firebaseio.com/.json. Dacă rădăcina este citibilă anonim, răspunsul este întregul arbore al bazei de date ca JSON. Un test mai conservator interoghează .json?shallow=true, care returnează doar cheile de nivel superior — un rezultat în orice caz.
• Cloud Storage. Scanerul interoghează https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Dacă răspunsul listează nume de fișiere fără autentificare, bucket-ul este listabil anonim. Stocarea listabilă este un rezultat chiar și când descărcările individuale ale fișierelor sunt refuzate — atacatorii enumeră bucket-ul pentru a găsi nume de fișiere ghicibile.

Cum arată de fapt capcana modului test

Documentația quickstart a Firebase include unul dintre cele mai copiate blocuri de reguli de pe internet:

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

Firebase obișnuia să adauge o expirare automată de 30 de zile pe aceste reguli. Asta s-a schimbat: astăzi regulile persistă pentru totdeauna, cu excepția cazului în care dezvoltatorul le înlocuiește. Instrumentele de codare AI — antrenate pe ani de documentație care include blocul de mod test — emit frecvent regula verbatim și îi spun dezvoltatorului „aceasta este regula ta de securitate". Nu este.

Alte variante care apar în producție, dar sunt la fel de permisive:

// 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;

• O variantă cu marcaj temporal viitor: o regulă care permite totul până la o dată îndepărtată în viitor. Niciodată nu expiră efectiv (vezi blocul evidențiat mai sus).
• allow read: if true; allow write: if request.auth != null; — citiri publice, orice utilizator autentificat poate scrie.
• allow read, write: if request.auth != null; — orice utilizator conectat poate citi sau scrie orice document, inclusiv datele altor utilizatori.

Ce să faci când scanerul găsește o regulă deschisă

Regulile Firebase deschise sunt o urgență în producție. Remedierea are aceeași formă în toate cele trei servicii: delimitează fiecare regulă la request.auth.uid împotriva unui câmp explicit de proprietar. Fiecare serviciu are propria sintaxă de reguli:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Legarea de segment de cale {userId} devine singurul document pe care utilizatorul îl poate atinge.

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; } } }. Convenție: stochează fișierele sub users/[uid]/[filename] și lasă calea să impună proprietatea.

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

Deployează regulile prin CLI-ul Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifică dacă noile reguli sunt în producție rulând din nou scanarea FixVibe — rezultatul baas.firebase-rules ar trebui să dispară.

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

Cum se compară asta cu instrumentele încorporate ale Firebase

Firebase Console îți arată regulile curente, dar nu le auditează împotriva comportamentului în runtime. Simulatorul Firebase Rules îți permite să testezi logica regulilor împotriva cererilor sintetice — util, dar local. Niciunul dintre instrumente nu îți spune ce returnează de fapt regulile tale de producție unui atacator anonim de pe internetul public. Un scaner extern precum FixVibe (sau Burp Suite cu configurare manuală) este singurul lucru care sondează din același unghi pe care l-ar face un atacator. App Check al Google atenuează abuzul, dar nu înlocuiește regulile corect delimitate.

Întrebări frecvente

Pași următori

Rulează o scanare FixVibe gratuită împotriva URL-ului tău de producție — verificarea baas.firebase-rules este livrată pe fiecare plan și semnalează reguli deschise în Firestore, Realtime Database și Cloud Storage. Pentru o explicație mai aprofundată specifică tiparului allow read, write: if true, vezi Firebase allow read, write: if true explicat. Pentru perspectiva generală asupra Supabase, Firebase, Clerk și Auth0, citește Scaner de configurări greșite BaaS.