Utilizza questa guida per comprendere le vulnerabilità comuni nelle configurazioni Firebase Security Rules, esaminare e proteggere meglio le tue regole e testare le modifiche prima di implementarle.
Se ricevi un avviso che ti informa che i tuoi dati non sono protetti correttamente, esamina questi errori comuni e aggiorna le regole vulnerabili.
Accedere a Firebase Security Rules
Per visualizzare Rules esistente, utilizza l'interfaccia a riga di comando Firebase o Console Firebase. Assicurati di modificare le regole utilizzando lo stesso metodo, regolarmente, per evitare di sovrascrivere erroneamente gli aggiornamenti. In caso di dubbi se le regole definite localmente riflettono gli aggiornamenti più recenti, console mostra sempre la versione di cui è stato eseguito il deployment più recente del tuo Firebase Security Rules.
Per accedere alle regole dalla console Firebase, seleziona progetto, quindi vai a Realtime Database, Cloud Firestore Spazio di archiviazione. Fai clic su Regole dopo aver selezionato il database o il bucket di archiviazione corretto.
Per accedere alle regole dall'interfaccia a riga di comando Firebase, vai a di regole del tuo account registrato nel file firebase.json.
Informazioni su Firebase Security Rules
Firebase Security Rules protegge i tuoi dati da utenti malintenzionati. Quando crei un database o Cloud Storage bucket nella console Firebase, puoi scegliere se negare l'accesso a tutti gli utenti (Modalità di blocco) o concedere l'accesso a tutti gli utenti (modalità di test). Potresti volere una configurazione più aperta di programmazione, assicurati di dedicare il tempo necessario a configurare correttamente le regole e proteggere i dati prima di eseguire il deployment dell'app.
Durante lo sviluppo dell'app e l'esecuzione di test su diverse configurazioni per il tuo usa uno degli emulatori Firebase locali per eseguire l'app in un ambiente di sviluppo locale.
Scenari comuni con regole non sicure
Rules che potresti aver configurato per impostazione predefinita o come devono essere esaminati e aggiornati prima di eseguire il deployment dell'app. Assicurati di proteggere adeguatamente i tuoi utenti dati evitando i seguenti inconvenienti comuni.
Accesso libero
Quando imposti il progetto Firebase, potresti aver impostato le regole per consentire l'accesso durante lo sviluppo. Potresti pensare di essere l'unica persona che utilizza ma se ne hai eseguito il deployment, è disponibile su internet. In caso contrario dopo aver autenticato gli utenti e configurando regole di sicurezza, chiunque indovina il tuo ID progetto può rubare, modificare o eliminare i dati.
Sconsigliato:accesso in lettura e scrittura per
tutti gli utenti.
Cloud Firestore// Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; } } } Realtime Database{ // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. "rules": { ".read": true, ".write": true } } Cloud Storage// Anyone can read or write to the bucket, even non-users of your app. // Because it is shared with App Engine, this will also make // files uploaded via App Engine public. // Warning: This rule makes every file in your Cloud Storage bucket accessible to any user. // Apply caution before using it in production, since it means anyone // can overwrite all your files. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write; } } } |
Soluzione: regole che limitano l'accesso in lettura e scrittura.
Crea regole pertinenti per la tua gerarchia di dati. Una delle soluzioni comuni a questo problema è la sicurezza basata sugli utenti con Firebase Authentication. Scopri di più sull'autenticazione degli utenti mediante le regole. Cloud FirestoreRealtime DatabaseCloud Storage |
Accesso per qualsiasi utente autenticato
A volte, Rules verifica che un utente abbia eseguito l'accesso, ma non ulteriori
limitare l'accesso in base a tale autenticazione. Se una delle regole include
auth != null
, conferma che tutti gli utenti che hanno eseguito l'accesso possono accedere a
e i dati di Google Cloud.
Opzione non consigliata: qualsiasi utente che ha eseguito l'accesso ha eseguito la lettura
e l'accesso in scrittura all'intero database.
Cloud Firestoreservice cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth.uid != null; } } } Realtime Database{ "rules": { ".read": "auth.uid !== null", ".write": "auth.uid !== null" } } Cloud Storage// Only authenticated users can read or write to the bucket service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if request.auth != null; } } } |
Soluzione: restringi l'accesso utilizzando la sicurezza
le condizioni di traffico.
Quando controlli l'autenticazione, potresti voler usare anche una delle proprietà di autenticazione per limitare ulteriormente l'accesso a utenti specifici per set di dati specifici. Scopri di più sulle diverse proprietà di autenticazione. Cloud FirestoreRealtime DatabaseCloud Storage |
(Realtime Database) Regole ereditate non correttamente
Realtime Database Security Rules a cascata, con regole più superficiali, con override dei percorsi principali nei nodi figlio più profondi. Quando scrivi una regola in un nodo figlio, ricorda di poter concedere solo privilegi aggiuntivi. Non puoi perfezionare o revocare l'accesso ai dati in un percorso più approfondito del database.
Sconsigliato:perfezionamento delle regole nei percorsi secondari
{ "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { /* ignored, since read was allowed already */ ".read": false } } } } |
Soluzione: scrivi regole per i percorsi principali generali e concedi privilegi più specifici per i percorsi secondari Se le tue esigenze di accesso ai dati richiedono una maggiore granularità, mantieni le regole granulari. Scopri di più sulla cascata di Realtime Database Security Rules in Principale sintassi di Realtime Database Security Rules. |
Accesso chiuso
Durante lo sviluppo dell'app, un altro approccio comune è mantenere bloccati. In genere, significa che hai bloccato l'accesso in lettura e scrittura per tutti gli utenti, come segue:
Cloud Firestore
// Deny read/write access to all users under any conditions service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if false; } } }
Realtime Database
{ "rules": { ".read": false, ".write": false } }
Cloud Storage
// Access to files through Cloud Storage is completely disallowed. // Files may still be accessible through App Engine or Google Cloud Storage APIs. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if false; } } }
Gli SDK Firebase Admin e Cloud Functions possono ancora accedere al tuo per configurare un database. Utilizza queste regole quando intendi usare Cloud Firestore o Realtime Database solo come server in combinazione con Firebase SDK Admin. Sebbene sia sicura, dovresti verificare che i client della tua app possano recuperare correttamente i dati.
Scopri di più su Cloud Firestore Security Rules e su come funzionano in Iniziare a utilizzare Cloud Firestore Security Rules.
Testa Cloud Firestore Security Rules
Per controllare il comportamento della tua app e verificare le configurazioni di Cloud Firestore Security Rules: utilizza l'emulatore di Firebase. Utilizza l'emulatore Cloud Firestore per eseguire e automatizzare i test di unità in un ambiente locale prima di implementare qualsiasi modifica.
Per convalidare rapidamente Firebase Security Rules nella console Firebase, usa il Simulatore di regole Firebase.