Firebase Security Rules: smetti di lasciare aperto il tuo database
Le web app Firebase leggono e scrivono su Firestore, Realtime Database e Cloud Storage direttamente dal browser, usando un oggetto di configurazione visibile a chiunque. Le Security Rules sono l'unica cosa che decide se una richiesta è consentita. Regole lasciate in test mode, o allentate per permettere tutto, espongono l'intero database a Internet.
Che cos'è
Le Security Rules sono un piccolo linguaggio di policy valutato sui server di Google per ogni lettura e scrittura. Ogni blocco match punta a un percorso — una collezione, un documento, una cartella di storage — e le istruzioni allow indicano quali operazioni sono consentite e a quali condizioni, usando request.auth (chi sta facendo la richiesta) e request.resource.data (cosa sta cercando di scrivere).
La config web di Firebase, compreso il suo apiKey, identifica solo il tuo progetto: non è un secret e da sola non concede alcun accesso. Ecco perché le regole contano così tanto: qualsiasi visitatore può inizializzare l'SDK Firebase con la tua config e interrogare il tuo database direttamente dalla console del proprio browser.
Perché è importante
La test mode di Firestore consente tutte le letture e scritture fino a una data di scadenza. Quando la scadenza arriva e l'app smette di funzionare, una "soluzione" comune è allow read, write: if true, che rende ogni documento leggibile e scrivibile da chiunque. I database Firebase esposti sono una fonte ricorrente di grandi fughe di dati, e trovarli e scaricarli è banale.
Le regole che verificano solo request.auth != null non sono molto meglio: chiunque può creare un account, spesso anche anonimo, e poi leggere i dati di tutti gli utenti. Senza validare le scritture, gli utenti possono anche modificare campi che non dovrebbero mai controllare, ad esempio impostando role: "admin" sul proprio profilo.
Come risolverlo
Nega tutto di default e concedi l'accesso collezione per collezione. Qui ogni utente può leggere e scrivere solo il proprio documento in users, e nient'altro è raggiungibile.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}
// Every other path is denied by default.
}
}Limita i campi che un utente può modificare, così non può promuoversi da solo né manomettere dati gestiti dal server. affectedKeys().hasOnly() rifiuta qualsiasi update che tocchi altri campi.
match /users/{userId} {
allow update: if request.auth.uid == userId
&& request.resource.data.diff(resource.data)
.affectedKeys().hasOnly(["displayName", "photoURL"]);
}Cerca nelle tue regole match /{document=**} combinato con un allow generico, if true e i timestamp di scadenza della test mode. Ricorda che Cloud Storage e Realtime Database hanno file di regole separati: proteggi anche quelli.
Usa il Rules Playground nella console Firebase o l'Emulator Suite con @firebase/rules-unit-testing per eseguire letture come utente non autenticato e come un altro utente autenticato. Un rapido controllo esterno è una richiesta REST non autenticata: se restituisce documenti, la collezione è pubblica.
curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/users"FAQ
Il mio apiKey di Firebase è un secret?
No. L'apiKey nella config web di Firebase identifica il tuo progetto ed è pensato per arrivare al browser. Proteggi i tuoi dati con le Security Rules e limita la chiave in Google Cloud alle API che la tua app usa davvero, così non può essere riutilizzata per altri servizi Google a pagamento.
request.auth != null è sufficiente?
Raramente. Dimostra solo che chi fa la richiesta ha effettuato l'accesso, non che i dati gli appartengano. Confronta request.auth.uid con il proprietario del documento, oppure verifica un ruolo che gli utenti non possono impostare da soli.
AppSafe controlla le mie regole Firebase?
AppSafe non interroga il tuo progetto Firebase, quindi non può valutare le tue regole: usa il Rules Playground o il controllo curl qui sopra. Segnala però le API key Google (formato AIza…) trovate nel tuo JavaScript, perché lo stesso formato è usato per servizi a pagamento come Maps o Gemini. Per una config web di Firebase è normale: assicurati solo che la chiave sia limitata.
La tua app è interessata?
AppSafe controlla questo e decine di altri problemi in un'unica scansione gratuita.
Scansiona la mia app gratisGuide correlate
Supabase Row Level Security (RLS): proteggi le tue tabelle
La tua anon key è pubblica. La RLS è l'unica cosa tra lei e i tuoi dati.
API key esposte nel JavaScript lato client
Tutto ciò che è nel tuo bundle è pubblico. Trattalo come tale.
Backup del database esposti: cosa succede quando /backup.sql è raggiungibile
Un dump .sql raggiungibile equivale a consegnare l'intero database.