Napraw niezabezpieczone reguły

Z tego przewodnika dowiesz się, jakie są typowe luki w zabezpieczeniach 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ą Twoje 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 opracować aplikację i uzyskać dostęp do bazy danych, musisz zmodyfikować te reguły i rozważyć przyznanie ogólnego dostępu wszystkim użytkownikom w środowisku programistycznym. Zanim jednak wdrożysz aplikację w środowisku produkcyjnym, poświęć trochę czasu na prawidłowe skonfigurowanie reguł i zabezpieczenie danych.

Podczas tworzenia aplikacji i testowania różnych konfiguracji reguł używaj emulatora Cloud Firestore, aby uruchamiać aplikację w lokalnym środowisku programistycznym.

Typowe scenariusze z niebezpiecznymi regułami

Cloud Firestore Security Rules, które zostały skonfigurowane domyślnie lub w trakcie tworzenia aplikacji za pomocą Cloud Firestore, należy sprawdzić i zaktualizować przed wdrożeniem aplikacji. 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ś ustawić reguły, które zezwalają na otwarty dostęp podczas tworzenia. Możesz sądzić, że jesteś jedyną osobą, która korzysta z Twojej aplikacji, ale jeśli ją wdrożysz, jest ona dostępna w internecie. Jeśli nie uwierzytelniasz użytkowników ani nie konfigurujesz reguł zabezpieczeń, każdy, kto zgadnie identyfikator Twojego projektu, może wykraść, zmodyfikować lub usunąć dane.

Nie zalecane: uprawnienia do odczytu i zapisu dla 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 ograniczające uprawnienia do odczytu i zapisu.

Utwórz reguły, które będą pasować do hierarchii danych. Jednym z popularnych rozwiązań tego problemu jest zabezpieczenie oparte na użytkownikach z uwierzytelnianiem Firestore.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 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 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ł zawiera parametr auth != null, potwierdź, że chcesz, aby każdy zalogowany użytkownik miał dostęp do 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 zabezpieczeń.

Podczas sprawdzania uwierzytelniania możesz też użyć jednej z właściwości uwierzytelniania, aby dodatkowo ograniczyć dostęp do określonych zbiorów danych dla konkretnych 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 do niezweryfikowanych adresów e-mail

Czasami Cloud Firestore Security Rules sprawdza, czy adres e-mail użytkownika należy do określonej domeny. Chociaż jest to ogólnie dobra praktyka, adresy e-mail nie są zawsze weryfikowane podczas logowania, dopóki użytkownik nie wykona dodatkowego kroku po otrzymaniu e-maila z weryfikacją. Upewnij się, że adres e-mail rzeczywiście należy do użytkownika.

Niezalecane: każdy użytkownik może zalogować się z dowolnym adresem e-mail.
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')
    }
  }
}
Rozwiązanie: ogranicz dostęp tylko do zweryfikowanych adresów e-mail.

Potwierdzanie adresów e-mail

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')
    }
  }
}

Dostęp zamknięty

Podczas tworzenia aplikacji możesz też zablokować swoje dane. 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 SDK Firebase Admin 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. Chociaż 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, z artykułu 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.

  1. Aby otworzyć Środowisko do testowania reguł, na karcie Reguły kliknij Środowisko do testowania reguł.
  2. W ustawieniach Testowanie reguł wybierz opcje testu, w tym:
    • Testowanie odczytów lub zapisów
    • konkretna lokalizacja w 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, aby zezwolić na zapisywanie danych);
  3. Kliknij Wykonaj i sprawdź wyniki na banerze nad oknem reguł.