// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true spiegato: cosa fa e come correggerlo

Q: Qual è la differenza tra if true e if request.auth != null ?

if true permette accesso anonimo — chiunque su Internet. if request.auth != null richiede qualsiasi utente loggato, che è meglio ma ancora sbagliato: qualsiasi utente della tua app può leggere i dati di qualsiasi altro utente. Le regole di produzione devono limitare all'utente o org specifico via request.auth.uid == resource.data.owner_uid o simile.

Q: E se la mia app è genuinamente public-read (blog, catalogo prodotti)?

Allora scrivi esplicitamente allow read: if true; allow write: if false; solo sulla collezione pubblica — non su ogni collezione nel tuo database. Usa una clausola match separata per collezione e non usare mai il wildcard ricorsivo '{'document=**'}' su regole scrivibili.

<code>allow read, write: if true;</code> è la singola configurazione errata Firebase più comune in produzione. È il default test-mode che la Firebase Console suggerisce quando crei un nuovo database, la regola che gli strumenti di codifica IA rigenerano dalla documentazione e la regola che apre l'intero tuo database Firestore a chiunque su Internet. Questo articolo spiega la sintassi precisamente, mostra cosa vede un attaccante quando questa regola è live e ti dà quattro sostituzioni progressivamente più rigorose adatte a diversi casi d'uso.

La sintassi, riga per riga

Un documento completo di regole Firestore in test-mode è sei righe:

firebase

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

Decodificato:

rules_version = '2'; seleziona il motore di regole v2 (corrente). Le vecchie regole v1 sono deprecate.
service cloud.firestore limita il blocco a Firestore. Realtime Database usa una sintassi diversa basata su JSON; Cloud Storage usa service firebase.storage.
match /databases/{database}/documents lega il database speciale (default) (la maggior parte dei progetti ne ha solo uno).
match /{document=**} è un wildcard ricorsivo. Il ** corrisponde a qualsiasi percorso di qualsiasi profondità. Combinato con {document}, questo cattura ogni documento in ogni collezione — una singola clausola match che governa l'intero database.
allow read, write: if true; è il corpo della regola. Sia read che write sono permessi; la condizione if true è, beh, sempre vera. read copre le operazioni get e list; write copre create, update e delete.

Effetto netto: qualsiasi client con l'ID del progetto Firebase e l'SDK giusto può leggere o scrivere qualsiasi documento in qualsiasi collezione. L'autenticazione non è richiesta. I rate limit non sono applicati.

Perché Firebase spedisce questo come default

Firebase vuole che tu stia codando nei primi 30 secondi dopo la creazione di un progetto. L'alternativa — costringerti a scrivere una regola corretta prima che qualsiasi lettura o scrittura funzioni — bloccherebbe l'onboarding. Quindi la console offre due opzioni quando crei un database: Modalità produzione (nega tutto, scrivi tu le regole) o Modalità test (permetti tutto per 30 giorni). La maggior parte degli sviluppatori clicca modalità test, poi dimentica di tornarci. I vecchi progetti avevano il timer di 30 giorni; i progetti attuali hanno una regola if true indefinita senza scadenza automatica.

Il problema strutturale: gli strumenti di codifica IA si addestrano su documentazione, tutorial e risposte di Stack Overflow che mostrano regole test-mode. Quando chiedi a Cursor o Claude Code "come configuro Firebase", la risposta spesso include l'esatto blocco allow read, write: if true come se fosse la regola di produzione. L'IA non sa — e non viene invitata a sapere — che questa regola non è sicura per la produzione.

Cosa vede un attaccante

Concretamente, un attaccante che conosce il tuo ID progetto Firebase (estraibile dal bundle di qualsiasi app deployata in 30 secondi) ed esegue quanto segue può elencare ogni documento in ogni collezione:

Una singola richiesta curl non autenticata basta per enumerare ogni collezione. Vedi il blocco evidenziato sotto.

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

La risposta è la lista completa delle collezioni top-level. Per ogni collezione, una seconda richiesta restituisce documenti. Non c'è alcun rate limit su questo percorso perché le regole if true accettano traffico anonimo. Abbiamo visto database Firebase con milioni di documenti enumerati in meno di un'ora.

Sul percorso di scrittura: un singolo POST con {fields} crea un nuovo documento. Gli attaccanti possono inquinare le tue collezioni con spazzatura, deturpare pagine user-facing che leggono da Firestore o usare il tuo database come message broker gratuito — la tua bolletta di utilizzo schizza, tu indaghi, la bolletta spiega il problema.

Quattro sostituzioni production-safe

Scegli la sostituzione che corrisponde al modello dati della tua app. Tutte e quattro assumono che tu abbia autenticazione utente (Firebase Auth o qualsiasi provider che emette un ID token Firebase):

Opzione 1: documenti di proprietà dell'utente

Pattern SaaS più comune. I documenti vivono sotto /users/{userId}/... e solo il proprietario può toccarli. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

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

Opzione 2: campo proprietario su ogni documento

Quando i documenti vivono in collezioni piatte (non annidati sotto ID utente), memorizza un campo owner_uid e controllalo. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Opzione 3: isolamento multi-tenant per org

Per SaaS B2B con dati limitati per org. Memorizza un campo org_id su ogni documento e controllalo contro il custom claim dell'utente. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Richiede di impostare il custom claim durante la registrazione via SDK Admin Firebase.

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Opzione 4: contenuto pubblico solo lettura

Per contenuto marketing, profili pubblici, cataloghi prodotti — qualsiasi cosa che è genuinamente lettura pubblica ma scrittura solo admin. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Il custom claim admin è impostato solo su account admin.

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Query di audit rapida

Prima di correggere, controlla se if true è effettivamente live. Apri Firebase Console → Firestore → Rules e cerca if true. Se lo trovi ovunque al di fuori di un commento, hai un risultato regola aperta. Il simulatore di regole nella stessa UI ti permette di rigiocare la richiesta dell'attaccante localmente — incolla un GET /users/somebody anonimo e conferma che il simulatore restituisce Allowed.

Conferma esterna: esegui una scansione FixVibe contro la tua URL di produzione. Il check baas.firebase-rules sonda le tue regole Firestore, Realtime Database e Storage e segnala lo stesso risultato che un attaccante scoprirebbe — indipendentemente da cosa mostra la Firebase Console.

Domande frequenti

Qual è la differenza tra <code>if true</code> e <code>if request.auth != null</code>?

if true permette accesso anonimo — chiunque su Internet. if request.auth != null richiede qualsiasi utente loggato, che è meglio ma ancora sbagliato: qualsiasi utente della tua app può leggere i dati di qualsiasi altro utente. Le regole di produzione devono limitare all'utente o org specifico via request.auth.uid == resource.data.owner_uid o simile.

Firebase fa mai scadere automaticamente le regole <code>if true</code>?

I vecchi progetti (pre-2023) avevano un timer di 30 giorni che convertiva le regole if true in if false. I progetti attuali no — la regola persiste indefinitamente finché non viene sostituita manualmente. Se hai creato il tuo progetto prima del 2023 e le tue regole sembrano a posto, ricontrolla: il timer potrebbe averle già ribaltate in if false, che blocca la tua stessa app.

Posso usare un controllo timestamp con data futura come rete di sicurezza?

No — una condizione timestamp non è un controllo di sicurezza. Fa scadere la regola aperta a una data futura, il che significa che fino a quella data gli attaccanti hanno accesso completo. E dimenticherai la data. Sostituisci if true con una regola limitata da auth, non da tempo.

E se la mia app è genuinamente public-read (blog, catalogo prodotti)?

Allora scrivi esplicitamente allow read: if true; allow write: if false; solo sulla collezione pubblica — non su ogni collezione nel tuo database. Usa una clausola match separata per collezione e non usare mai il wildcard ricorsivo {document=**} su regole scrivibili.

Prossimi passi

Esegui una scansione FixVibe contro la tua URL di produzione — il check baas.firebase-rules conferma se if true è attualmente sfruttabile da Internet pubblico. Per i meccanismi dello scanner e le rilevazioni parallele per Realtime Database e Storage, vedi Scanner di regole Firebase. Per la classe equivalente di configurazione errata su Supabase, leggi Scanner RLS Supabase.