Z tego przewodnika dowiesz się, jakie częste luki w zabezpieczeniach występują w konfiguracjach Cloud Firestore Security Rules, jak sprawdzić i poprawić zabezpieczenia własnych reguł oraz jak przetestować zmiany przed ich wdrożeniem.
Jeśli otrzymasz alert, że baza danych Cloud Firestore nie jest odpowiednio zabezpieczona, możesz rozwiązać problemy z lukami w zabezpieczeniach, modyfikując i testując Cloud Firestore Security Rules.
Aby wyświetlić istniejące reguły zabezpieczeń, otwórz w konsoli Firebase kartę Reguły.
Informacje o Cloud Firestore Security Rules
Cloud Firestore Security Rules chronić dane przed złośliwymi użytkownikami. Domyślne reguły dotyczące dowolnego wystąpienia Cloud Firestore utworzonego w konsoli Firebase odmawiają dostępu wszystkim użytkownikom. Aby stworzyć aplikację i uzyskać dostęp do bazy danych, zmodyfikuj te reguły i rozważ przyznanie dostępu ogólnego wszystkim użytkownikom w środowisku programistycznym. Zanim jednak wdrożysz aplikację w środowisku produkcyjnym, poświęć trochę czasu na prawidłową konfigurację reguł i zabezpieczenie danych.
Gdy tworzysz aplikację i testujesz różne konfiguracje reguł, możesz uruchomić ją w lokalnym środowisku programistycznym za pomocą emulatora Cloud Firestore.
Typowe scenariusze dotyczące niepewnych reguł
Zanim wdrożysz aplikację, sprawdź i zaktualizuj Cloud Firestore Security Rules, które mogły zostać skonfigurowane domyślnie lub podczas tworzenia aplikacji za pomocą Cloud Firestore. Upewnij się, że dane użytkowników są odpowiednio zabezpieczone, unikając tych typowych błędów.
Dostęp otwarty
Podczas konfigurowania Cloud Firestore mogłeś/mogłaś ustawić reguły, które zezwalają na otwarty dostęp podczas tworzenia. Może Ci się wydawać, że jesteś jedyną osobą, która korzysta z aplikacji, ale jeśli już ją wdrożyłeś, jest ona dostępna w internecie. Jeśli nie uwierzytelniasz użytkowników ani nie konfigurujesz reguł zabezpieczeń, każda osoba, która zgadnie identyfikator Twojego projektu, może wykraść, zmodyfikować lub usunąć dane.
Niezalecane: uprawnienia do odczytu i zapisu w przypadku wszystkich użytkowników. |
// 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; } } }
Rozwiązanie: reguły, które ograniczają dostęp do odczytu i zapisu.
Utwórz reguły, które będą pasować do hierarchii danych. Jednym z najczęstszych rozwiązań tego problemu jest zabezpieczenie oparte na użytkownikach za pomocą Firebase Authentication. Dowiedz się więcej o uwierzytelnianiu użytkowników za pomocą reguł. |
Tylko właściciele treści
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; } } }
Dostęp publiczny i prywatny
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; } } }
Dostęp dla każdego uwierzytelnionego użytkownika
Czasami Cloud Firestore Security Rules sprawdza, czy użytkownik jest zalogowany, ale nie ogranicza dostępu na podstawie uwierzytelnienia. Jeśli jedna z reguł obejmuje regułę auth != null
, potwierdź, że chcesz, aby każdy zalogowany użytkownik miał dostęp do tych danych.
Niezalecane: każdy zalogowany użytkownik ma dostęp do odczytu i edycji całej bazy danych. |
service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth != null; } } }
Rozwiązanie: ogranicz dostęp za pomocą warunków bezpieczeństwa.
Podczas sprawdzania uwierzytelniania możesz też użyć jednej z właściwości uwierzytelniania, aby jeszcze bardziej ograniczyć dostęp do określonych zbiorów danych do określonych użytkowników. Dowiedz się więcej o dodawaniu warunków zabezpieczeń i dostępie na podstawie roli. |
Dostęp na podstawie roli
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. } } }
Dostęp na podstawie atrybutów
// 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; } } }
Dostęp mieszany (publiczny i prywatny)
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 } } }
Dostęp zamknięty
Innym popularnym podejściem podczas tworzenia aplikacji jest blokowanie danych. Zwykle oznacza to, że dostęp do odczytu i zapisu został zamknięty dla wszystkich użytkowników w następujący sposób:
// Deny read/write access to all users under any conditions
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Pakiety Firebase Admin SDK i Cloud Functions nadal mają dostęp do Twojej bazy danych. Używaj tych reguł, gdy chcesz używać Cloud Firestore jako backendu tylko na serwerze w połączeniu z pakietem Firebase Admin SDK. Mimo że jest to bezpieczne, sprawdź, czy klienci aplikacji mogą prawidłowo pobierać dane.
Dowiedz się więcej o Cloud Firestore Security Rules i o tym, jak działają te funkcje, w artykule Początkujący: korzystanie z Cloud Firestore Security Rules.
Sprawdź aplikację Cloud Firestore Security Rules
Aby sprawdzić działanie aplikacji i sprawdzać konfiguracje Cloud Firestore Security Rules, użyj Cloud Firestore emulatora. Przed wdrożeniem zmian uruchom i zautomatyzuj testy jednostkowe w środowisku lokalnym za pomocą emulatora Cloud Firestore.
Aby szybko przetestować zaktualizowany Cloud Firestore Security Rules w konsoli Firebase, użyj narzędzia Rules Playground.
- Aby otworzyć Playground reguł, na karcie Reguły kliknij Platforma do tworzenia reguł.
- W ustawieniach Testowanie reguł wybierz opcje testu, w tym:
- Testowanie odczytu lub zapisu
- konkretna lokalizacja w Twojej bazie danych, podana jako ścieżka;
- Typ uwierzytelniania – niezalogowany, zalogowany anonimowy użytkownik lub konkretny identyfikator użytkownika
- dane dotyczące dokumentu, do których odwołują się Twoje reguły (np. jeśli Twoje reguły wymagają obecności określonego pola, zanim zezwolą na zapisanie danych);
- Kliknij Wykonaj i sprawdź wyniki na banerze nad oknem reguł.