Correggi le regole non sicure

Utilizza questa guida per comprendere le vulnerabilità comuni nelle Cloud Firestore Security Rules configurazioni, esaminare e proteggere meglio le tue regole, e testare le modifiche prima di eseguirne il deployment.

Se ricevi un avviso che indica che il database Cloud Firestore non è protetto correttamente, puoi risolvere le vulnerabilità modificando e testando le Cloud Firestore Security Rules.

Per visualizzare le regole di sicurezza esistenti, vai alla scheda Regole nella console Firebase.

Informazioni sulle regole di sicurezza di Cloud FirestoreCloud Firestore Security Rules

Cloud Firestore Security Rules proteggono i dati dagli utenti malintenzionati. Le regole predefinite per qualsiasi istanza Cloud Firestore creata nella console Firebase negano l'accesso a tutti gli utenti. Per sviluppare l'app e accedere al database, dovrai modificare queste regole e potresti prendere in considerazione la possibilità di concedere l'accesso generale a tutti gli utenti in un ambiente di sviluppo. Prima di eseguire il deployment dell'app in un ambiente di produzione, prenditi il tempo necessario per configurare correttamente le regole e proteggere i dati.

Durante lo sviluppo dell'app e il test di diverse configurazioni per le regole, utilizza l'Cloud Firestoreemulatore per eseguire l'app in un ambiente di sviluppo locale.

Scenari comuni con regole non sicure

Le Cloud Firestore Security Rules che potresti aver configurato per impostazione predefinita o mentre lavoravi inizialmente allo sviluppo dell'app con Cloud Firestore devono essere esaminate e aggiornate prima di eseguire il deployment dell'app. Assicurati di proteggere correttamente i dati degli utenti evitando le seguenti insidie comuni.

Accesso aperto

Quando hai configurato Cloud Firestore, potresti aver impostato le regole in modo da consentire l'accesso aperto durante lo sviluppo. Potresti pensare di essere l'unica persona a utilizzare l'app, ma se hai eseguito il deployment, è disponibile su internet. Se non autentichi gli utenti e non configuri le regole di sicurezza, chiunque indovini l'ID progetto può rubare, modificare o eliminare i dati.

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;

    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}
  

Accesso per qualsiasi utente autenticato

A volte, Cloud Firestore Security Rules verificano che un utente abbia eseguito l'accesso, ma non limitano ulteriormente l'accesso in base all'autenticazione. Se una delle tue regole include auth != null, verifica di voler consentire l'accesso ai dati a qualsiasi utente che ha eseguito l'accesso.

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

Accesso per indirizzi email non verificati

A volte, Cloud Firestore Security Rules verificano che l'email di un utente appartenga a un dominio specifico. Sebbene questa sia in genere una buona pratica, le email non vengono sempre verificate durante l'accesso finché l'utente non esegue un passaggio aggiuntivo al ricevimento di un'email di verifica. Assicurati di verificare che l'email appartenga effettivamente all'utente.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

Accesso chiuso

Durante lo sviluppo dell'app, un altro approccio comune consiste nel mantenere i dati bloccati. In genere, questo significa che hai chiuso l'accesso in lettura e scrittura a tutti gli utenti, come segue:

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Gli SDK Admin Firebase e Cloud Functions possono comunque accedere al database. Utilizza queste regole quando intendi utilizzare Cloud Firestore come backend solo server in combinazione con l'SDK Admin Firebase. Sebbene sia sicuro, devi verificare che i client dell'app possano recuperare correttamente i dati.

Scopri di più su Cloud Firestore Security Rules e sul loro funzionamento in Inizia a utilizzare Cloud Firestore Security Rules.

Controlla le tue Cloud Firestore Security Rules

Per controllare il comportamento dell'app e verificare le configurazioni Cloud Firestore Security Rules, utilizza l'Cloud Firestore emulatore. Utilizza l'Cloud Firestore emulatore per eseguire e automatizzare i test delle unità in un ambiente locale prima di eseguire il deployment di eventuali modifiche.

Per testare rapidamente le regole di sicurezza di Cloud Firestore aggiornate nella console Firebase, utilizza lo strumento Rules Playground.Cloud Firestore Security Rules

1. Per aprire Rules Playground, fai clic su Rules Playground dalla scheda Regole.
2. Nelle impostazioni di Rules Playground, seleziona le opzioni per il test, tra cui:
   • Test di letture o scritture
   • Un percorso specifico nel database
   • Tipo di autenticazione: utente anonimo non autenticato, autenticato o un ID utente specifico
   • Dati specifici del documento a cui fanno riferimento in modo specifico le regole (ad esempio, se le regole richiedono la presenza di un campo specifico prima di consentire una scrittura)
3. Fai clic su Esegui e cerca i risultati nel banner sopra la finestra delle regole.