Scanner di regole Firebase: trova regole aperte in Firestore, Realtime Database e Storage

Come lo scanner trova regole Firebase aperte

I servizi Firebase espongono forme di URL ben note e prevedibili. Uno scanner senza credenziali può sondare ciascuno e osservare se le letture anonime hanno successo. Il check baas.firebase-rules di FixVibe esegue tre sondaggi indipendenti — uno per servizio 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. Lo scanner sonda https://[project-id]-default-rtdb.firebaseio.com/.json. Se la radice è leggibile anonimamente, la risposta è l'intero albero del database come JSON. Un test più conservativo interroga .json?shallow=true, che restituisce solo le chiavi top-level — un risultato in entrambi i casi.
• Cloud Storage. Lo scanner interroga https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Se la risposta elenca nomi di file senza autenticazione, il bucket è elencabile anonimamente. Storage elencabile è un risultato anche quando i singoli download di file sono negati — gli attaccanti enumerano il bucket per trovare nomi di file indovinabili.

Come appare davvero il footgun del test-mode

La documentazione di quickstart di Firebase include uno dei blocchi di regole più copiati di Internet:

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

Firebase aggiungeva una scadenza automatica di 30 giorni a queste regole. Questo è cambiato: oggi le regole persistono per sempre a meno che lo sviluppatore non le sostituisca. Gli strumenti di codifica IA — addestrati su anni di documentazione che include il blocco test-mode — lo emettono spesso letteralmente e dicono allo sviluppatore "questa è la tua regola di sicurezza". Non lo è.

Altre varianti che compaiono in produzione ma sono ugualmente permissive:

// 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 timestamp futuro: una regola che permette tutto fino a una data lontana nel futuro. Non scade mai effettivamente (vedi il blocco evidenziato sopra).
• allow read: if true; allow write: if request.auth != null; — letture pubbliche, qualsiasi utente autenticato può scrivere.
• allow read, write: if request.auth != null; — qualsiasi utente loggato può leggere o scrivere qualsiasi documento, inclusi dati di altri utenti.

Cosa fare quando lo scanner trova una regola aperta

Le regole aperte di Firebase sono un'emergenza in produzione. La correzione ha la stessa forma in tutti e tre i servizi: limita ogni regola a request.auth.uid contro un campo proprietario esplicito. Ogni servizio ha la sua sintassi di regole:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Il binding del segmento di percorso {userId} diventa l'unico documento che l'utente può toccare.

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; } } }. Convenzione: memorizza i file sotto users/[uid]/[filename] e lascia che il percorso imponga la proprietà.

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

Deploya le regole via la CLI Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifica che le nuove regole siano in produzione rieseguendo la scansione FixVibe — il risultato baas.firebase-rules dovrebbe scomparire.

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

Come si confronta con gli strumenti integrati di Firebase

La Firebase Console ti mostra le regole correnti ma non le audita contro il comportamento runtime. Il simulatore di regole Firebase ti permette di testare la logica delle regole contro richieste sintetiche — utile ma locale. Nessuno dei due strumenti ti dice cosa le tue regole di produzione restituiscono effettivamente a un attaccante anonimo su Internet pubblico. Uno scanner esterno come FixVibe (o Burp Suite con configurazione manuale) è l'unica cosa che sonda dallo stesso angolo di un attaccante. L<em>App Check</em> di Google mitiga labuso ma non sostituisce regole correttamente limitate.

Domande frequenti

Prossimi passi

Esegui una scansione FixVibe gratuita contro la tua URL di produzione — il check baas.firebase-rules è in ogni piano e segnala regole aperte in Firestore, Realtime Database e Cloud Storage. Per una spiegazione più approfondita del pattern allow read, write: if true in particolare, vedi Firebase allow read, write: if true spiegato. Per la panoramica su Supabase, Firebase, Clerk e Auth0, leggi Scanner di configurazioni errate BaaS.