Verwenden Sie diesen Leitfaden, um sich mit gängigen Sicherheitslücken in Cloud Firestore Security Rules-Konfigurationen vertraut zu machen, Ihre eigenen Regeln zu prüfen und besser abzusichern und Ihre Änderungen vor der Bereitstellung zu testen.
Wenn Sie eine Benachrichtigung erhalten, dass Ihre Cloud Firestore-Datenbank nicht ordnungsgemäß geschützt ist, können Sie die Sicherheitslücken beheben, indem Sie Ihre Cloud Firestore Security Rules ändern und testen.
Rufen Sie in der Firebase Console den Tab „Regeln“ auf, um Ihre vorhandenen Sicherheitsregeln anzusehen.
Informationen zu Cloud Firestore Security Rules
Cloud Firestore Security Rules schützen Ihre Daten vor böswilligen Nutzern. Die Standardregeln jeder Cloud Firestore-Instanz, die in der Firebase-Konsole erstellt wurde, verweigern allen Nutzern den Zugriff. Damit Sie Ihre Anwendung entwickeln und auf Ihre Datenbank zugreifen können, müssen Sie diese Regeln ändern und möglicherweise allen Nutzern in einer Entwicklungsumgebung uneingeschränkten Zugriff gewähren. Bevor Sie Ihre Anwendung in einer Produktionsumgebung bereitstellen, sollten Sie sich jedoch die Zeit nehmen, Ihre Regeln entsprechend zu konfigurieren und Ihre Daten zu schützen.
Wenn Sie Ihre Anwendung entwickeln und verschiedene Konfigurationen für Ihre Regeln testen möchten, können Sie die Anwendung mit dem Cloud Firestore-Emulator in einer lokalen Entwicklungsumgebung ausführen.
Häufige Szenarien mit unsicheren Regeln
Die Cloud Firestore Security Rules, die Sie möglicherweise standardmäßig eingerichtet haben oder bei der anfänglichen Entwicklung Ihrer Anwendung mit Cloud Firestore gearbeitet haben, sollten vor der Bereitstellung der Anwendung geprüft und aktualisiert werden. Sorgen Sie dafür, dass die Daten Ihrer Nutzer ordnungsgemäß geschützt sind, und vermeiden Sie die folgenden häufigen Fallstricke.
Unbeschränkter Zugriff
Bei der Einrichtung von Cloud Firestore haben Sie möglicherweise Ihre Regeln so festgelegt, dass für die Entwicklung ein offener Zugriff möglich ist. Eventuell gehen Sie auch davon aus, dass Sie die einzige Person sind, die Ihre Anwendung nutzt. Allerdings ist sie nach dem Bereitstellen im Internet verfügbar. Wenn Sie Nutzer nicht authentifizieren und keine Sicherheitsregeln konfigurieren, kann jeder, der Ihre Projekt-ID errät, die Daten stehlen, ändern oder löschen.
| Nicht empfohlen: Alle Nutzer haben Lese- und Schreibzugriff. |
// 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; } } }
| Lösung: Legen Sie Regeln fest, die den Lese- und Schreibzugriff beschränken. Erstellen Sie Regeln, die für Ihre Datenhierarchie sinnvoll sind. Eine der gängigsten Lösungen für diese Unsicherheit ist die nutzerbasierte Sicherheit mit Firebase Authentication. Weitere Informationen dazu finden Sie unter Nutzer mit Regeln authentifizieren. |
Nur Eigentümer
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; } } }
Gemischter öffentlicher und privater Zugriff
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; } } }
Zugriff für jeden authentifizierten Nutzer
Manchmal prüfen Cloud Firestore Security Rules-Regeln, ob ein Nutzer angemeldet ist, schränken den Zugriff anhand dieser Authentifizierung jedoch nicht weiter ein. Wenn eine Ihrer Regeln auth != null enthält, haben alle angemeldeten Nutzer Zugriff auf die Daten.
| Nicht empfohlen: Jeder angemeldete Nutzer hat Lese- und Schreibzugriff auf Ihre gesamte Datenbank. |
service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth != null; } } }
| Lösung: Grenzen Sie den Zugriff mithilfe von Sicherheitsbedingungen ein. Wenn Sie die Authentifizierung prüfen lassen, können Sie auch eines der Authentifizierungsattribute verwenden, um den Zugriff für bestimmte Nutzer und bestimmte Datensätze weiter einzuschränken. Weitere Informationen finden Sie unter Sicherheitsbedingungen hinzufügen und rollenbasierter Zugriff. |
Rollenbasierter Zugriff
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. } } }
Attributbasierter Zugriff
// 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; } } }
Gemischter öffentlicher und privater Zugriff
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
}
}
}
Geschlossener Zugriff
Ein weiterer gängiger Ansatz während der Entwicklung Ihrer Anwendung besteht darin, Ihre Daten zu sperren. In der Regel bedeutet dies, dass Sie den Lese- und Schreibzugriff für alle Nutzer folgendermaßen gesperrt haben:
// Deny read/write access to all users under any conditions
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Die Firebase Admin SDKs und Cloud Functions haben aber weiterhin Zugriff auf Ihre Datenbank. Verwenden Sie diese Regeln, wenn Sie Cloud Firestore zusammen mit dem Firebase Admin SDK als reines Server-Back-End verwenden möchten. Dies ist zwar sicher, Sie müssen aber testen, ob die Clients Ihrer Anwendung Daten ordnungsgemäß abrufen können.
Weitere Informationen zu Cloud Firestore Security Rules und ihrer Funktionsweise finden Sie unter Erste Schritte mit Cloud Firestore Security Rules.
In Cloud Firestore Security Rules nachsehen
Verwenden Sie den Cloud Firestore-Emulator, um das Verhalten Ihrer Anwendung und die Konfigurationen Ihrer Cloud Firestore Security Rules-Regeln zu prüfen. Verwenden Sie den Cloud Firestore-Emulator, um Einheitentests in einer lokalen Umgebung auszuführen und zu automatisieren, bevor Sie Änderungen bereitstellen.
Mit dem „Rules Playground“-Tool können Sie die aktualisierte Cloud Firestore Security Rules schnell in der Firebase Console testen.
- Klicken Sie zum Öffnen von Regel-Playground auf dem Tab Regeln auf Regel-Playground.
- Wählen Sie in den Einstellungen zu Regel-Playground Optionen für Ihren Test aus, wie z. B. die folgenden:
- Lese- oder Schreibvorgänge testen
- Unter Standort einen bestimmten Standort in Ihrer Datenbank als Pfad
- Authentifizierungstyp — nicht authentifizierter Nutzer, authentifizierter anonymer Nutzer oder eine bestimmte Nutzer-ID
- Dokumentspezifische Daten, auf die Ihre Regeln speziell verweisen (z. B. wenn für Ihre Regeln das Vorhandensein eines bestimmten Felds erforderlich ist, bevor ein Schreibvorgang erlaubt wird)
- Klicken Sie auf Ausführen und sehen Sie sich die Ergebnisse im Banner über dem Fenster mit den Regeln an.