Firebase è il backend preferito di molte app create con l'IA: Lovable, Bolt o Cursor lo collegano in pochi minuti e hai autenticazione, database e file senza montare un server. Il problema è che il suo modello di sicurezza è l'opposto di quello di un backend tradizionale. Qui il browser parla direttamente con il database, quindi non c'è un server che filtra le richieste: le regole di sicurezza sono la tua unica barriera, e una regola scritta male lascia tutti i dati in bella vista. Questa guida ripassa i dieci errori che si ripetono di più, con la regola sbagliata e quella giusta in ogni caso, e finisce con come verificarlo da solo.
1. Regole in modalità test, o quello che viene dopo
Quando crei un database, Firebase ti propone la "modalità test": tutto aperto per trenta giorni. La regola ha questo aspetto:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2026, 11, 3);
}
}
}Fino a quella data, chiunque abbia il tuo projectId (che sta nel codice del browser) può leggere e scrivere tutto il database. E il peggio arriva dopo: alla scadenza l'app smette di funzionare, lo sviluppatore cerca una soluzione rapida e sostituisce la data con if true. Ora il buco è permanente. La soluzione è scrivere regole per collezione dal primo giorno, basate su chi è l'utente e di chi è il documento.
2. allow read: if true sui dati degli utenti
Ci sono collezioni che possono essere pubbliche (un catalogo prodotti, i post di un blog). Ma allow read: if true su users, orders o messages significa che chiunque può scaricare la lista completa. Il modo corretto di proteggere i documenti per utente:
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}Ogni utente legge e scrive solo il suo documento. Per dati condivisi tra più persone (un team, un progetto) salva la lista dei membri nel documento e verificala nella regola.
3. Confondere "autenticato" con "autorizzato"
La regola allow read: if request.auth != null sembra sicura ed è l'errore più comune. Dice: qualsiasi utente con sessione può leggere. Ma registrarsi alla tua app è gratis e richiede dieci secondi, quindi in pratica è come essere aperti. Autenticato risponde a chi sei; autorizzato, a cosa puoi vedere. Le regole devono rispondere alla seconda.
4. Dati sensibili in documenti leggibili
Un profilo pubblico con nome e avatar è ragionevole. Lo stesso documento con email, telefono, indirizzo e un token di accesso, no. Se altri utenti devono poter vedere parte del profilo, separa il pubblico dal privato in due documenti o in una sottocollezione private con regole più strette. Ciò che non sta in un documento leggibile non può trapelare.
5. Pensare che la configurazione di Firebase sia un segreto
L'oggetto con apiKey, authDomain e projectId va nel browser per design: identifica il tuo progetto, non autorizza nulla. Vederlo nel sorgente non è un difetto, e non è ciò che devi nascondere. Quello che devi fare con quella chiave è limitarla nella console di Google Cloud ai domini del tuo sito (restrizione per referrer HTTP) e attivare App Check, che richiede che le richieste arrivino dalla tua app reale e non da uno script.
6. Le altre chiavi invece sono segrete
L'errore grave è un altro: accanto alla configurazione di Firebase, il bundle porta la chiave segreta di Stripe, quella di OpenAI o quella di un servizio email perché "così era più facile". Quelle chiavi danno accesso a denaro e ad account di terzi. Il loro posto è una Cloud Function con i segreti nelle variabili d'ambiente, e il browser chiama la funzione, mai il servizio direttamente. Il dettaglio è in segreti che la tua app fa trapelare nel browser.
7. Storage senza regole proprie
Cloud Storage ha le sue regole e di solito ci si dimentica. Con allow read, write: if request.auth != null qualsiasi utente registrato può leggere i file degli altri, caricare quello che vuole in qualsiasi percorso e riempire la tua quota. Una regola ragionevole limita il percorso all'utente e valida dimensione e tipo:
match /users/{userId}/{fileName} {
allow read: if request.auth != null && request.auth.uid == userId;
allow write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*');
}8. Realtime Database aperto
Se usi il database in tempo reale al posto di Firestore, l'equivalente è ".read": true nella root. Le regole sono un altro linguaggio, ma la logica è la stessa: niente aperto nella root, e permessi per ramo con auth.uid.
9. Scrivere senza validare
Permettere la scrittura al proprietario del documento non basta se non validi cosa scrive. Un utente può aggiungere isAdmin: true o plan: "pro" al proprio profilo dalla console del browser. Valida i campi con request.resource.data: quali chiavi esistono, di che tipo sono e che i campi sensibili non cambino.
allow update: if request.auth.uid == userId
&& !request.resource.data.diff(resource.data).affectedKeys()
.hasAny(['isAdmin', 'plan', 'credits']);10. Dimenticare la fattura
Firebase fa pagare per lettura. Una regola che permette list senza limite su una collezione grande lascia che uno script legga milioni di documenti e ti generi una fattura inattesa. Limita le query dalle regole (request.query.limit <= 100), attiva App Check e imposta avvisi di budget in Google Cloud.
Come verificarlo da solo
- Simulatore di regole. Nella console di Firebase, scheda Regole, c'è un simulatore in cui provi una lettura come utente anonimo o con un UID specifico. Prova a leggere
userssenza sessione: deve essere negato. - Emulatore con test. L'emulatore locale permette di scrivere test automatici delle regole. È l'unico modo per non romperle quando le cambi.
- Dall'esterno, senza token. L'API REST di Firestore risponde a chiunque:
curl "https://firestore.googleapis.com/v1/projects/TUO_PROGETTO/databases/(default)/documents/users"Se restituisce documenti, quella collezione è aperta. Se restituisce un errore di permessi, la regola funziona. Ripeti con ogni collezione che hai.
Scanaris controlla il tuo Firebase dall'esterno
Scanaris rileva la configurazione di Firebase nel tuo bundle, verifica se le collezioni abituali rispondono senza autenticazione, cerca altre chiavi che non dovrebbero stare nel browser e controlla header, CORS e file esposti. Per ogni riscontro ti dà un fix prompt con la regola o la modifica esatta da incollare in Lovable, Bolt o Cursor. Sono controlli in sola lettura su ciò che è già pubblico. La lista completa dei rischi è nella guida alla sicurezza per Firebase, e prima di lanciare conviene ripassare la checklist di sicurezza.
Domande frequenti
È un problema che la mia apiKey di Firebase sia nel codice?
Non di per sé: identifica il progetto, non dà permessi. Ciò che protegge i dati sono le regole. Detto questo, limita la chiave ai tuoi domini e attiva App Check per evitare abusi.
Cosa faccio se le mie regole sono aperte in questo momento?
Chiudi prima: metti regole per collezione con request.auth.uid anche se qualche funzione smette di andare, e sistema l'app dopo. Poi controlla nei log di utilizzo se ci sono state letture anomale e, se c'erano dati personali esposti, valuta se devi notificarlo.
Posso chiedere alla mia IA di scrivere le regole?
Sì, e di solito lo fa bene se le dai la struttura delle tue collezioni e chi deve vedere cosa. Ma provale nel simulatore prima di pubblicare: anche un'IA scrive if request.auth != null credendo che sia sicuro.