Napraw niezabezpieczone reguły

Z tego przewodnika dowiesz się o typowych lukach w zabezpieczeniach w Cloud Firestore Security Rules konfiguracjach, sprawdzisz i lepiej zabezpieczysz własne reguły, oraz przetestujesz zmiany przed ich wdrożeniem.

Jeśli otrzymasz alert, że Twoja baza danych Cloud Firestore nie jest odpowiednio zabezpieczona, możesz rozwiązać problemy z zabezpieczeniami, modyfikując i testując Cloud Firestore Security Rules.

Aby wyświetlić dotychczasowe reguły bezpieczeństwa, otwórz kartę Reguły w konsoli Firebase.

Informacje o Cloud Firestore Security Rules

Cloud Firestore Security Rules chronią Twoje dane przed złośliwymi użytkownikami. Domyślne reguły dla każdej instancji Cloud Firestore utworzonej w konsoli Firebase odmawiają dostępu wszystkim użytkownikom. Aby rozwijać aplikację i uzyskiwać dostęp do bazy danych, musisz zmodyfikować te reguły. Możesz też rozważyć przyznanie wszystkim użytkownikom w środowisku programistycznym nieograniczonego dostępu. Zanim jednak wdrożysz aplikację w środowisku produkcyjnym, poświęć czas na prawidłowe skonfigurowanie reguł i zabezpieczenie danych.

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

Typowe scenariusze z niezabezpieczonymi regułami

Cloud Firestore Security Rules które mogły zostać skonfigurowane domyślnie lub podczas początkowego tworzenia aplikacji za pomocą Cloud Firestore należy sprawdzić i zaktualizować przed wdrożeniem aplikacji. Aby odpowiednio zabezpieczyć dane użytkowników, unikaj tych typowych pułapek.

Otwarty dostęp

Podczas konfigurowania Cloud Firestore mogłeś(-aś) ustawić reguły, które zezwalają na otwarty dostęp podczas programowania. Możesz myśleć, że tylko Ty używasz aplikacji, ale jeśli ją wdrożysz, będzie ona dostępna w internecie. Jeśli nie uwierzytelniasz użytkowników i nie konfigurujesz reguł bezpieczeństwa, każdy, kto odgadnie identyfikator Twojego projektu, może ukraść, zmodyfikować lub usunąć dane.

// 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;
    }
  }
}
  

Dostęp dla każdego uwierzytelnionego użytkownika

Czasami Cloud Firestore Security Rules sprawdzają, czy użytkownik jest zalogowany, ale nie ograniczają dostępu na podstawie tego uwierzytelnienia. Jeśli jedna z Twoich reguł zawiera auth != null, potwierdź, że chcesz, aby każdy zalogowany użytkownik miał dostęp do danych.

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

Dostęp do niezweryfikowanych adresów e-mail

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

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

Dostęp zamknięty

Podczas tworzenia aplikacji często stosuje się też podejście polegające na blokowaniu dostępu do danych. Zazwyczaj oznacza to, że zablokowano uprawnienia do odczytu i zapisu dla wszystkich użytkowników w ten 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 mogą uzyskiwać dostęp do Twojej bazy danych. Używaj tych reguł, jeśli chcesz używać Cloud Firestore jako backendu tylko po stronie serwera w połączeniu z pakietem Firebase Admin SDK. Chociaż jest to bezpieczne, musisz sprawdzić, czy klienci Twojej aplikacji mogą prawidłowo pobierać dane.

Więcej informacji o Cloud Firestore Security Rules i ich działaniu znajdziesz w artykule Wprowadzenie do Cloud Firestore Security Rules.

Sprawdzanie Cloud Firestore Security Rules

Aby sprawdzić działanie aplikacji i zweryfikować konfiguracje Cloud Firestore Security Rules, użyj emulatora Cloud Firestore. Użyj Cloud Firestore emulatora, aby uruchamiać i automatyzować testy jednostkowe w środowisku lokalnym przed wdrożeniem jakichkolwiek zmian.

Aby szybko przetestować zaktualizowane Cloud Firestore Security Rules w konsoli Firebase, użyj narzędzia Plac zabaw z regułami.

1. Aby otworzyć Plac zabaw z regułami, kliknij Plac zabaw z regułami na karcie Reguły.
2. W ustawieniach Placu zabaw z regułami wybierz opcje testu, w tym:
   • Testowanie odczytu lub zapisu
   • Określona lokalizacja w bazie danych jako ścieżka
   • Typ uwierzytelnienia – nieuwierzytelniony, uwierzytelniony użytkownik anonimowy lub konkretny identyfikator użytkownika
   • Dane dotyczące dokumentu, do których odwołują się Twoje reguły (np. jeśli reguły wymagają obecności określonego pola przed zezwoleniem na zapis)
3. Kliknij Uruchom i poszukaj wyników w banerze nad oknem reguł.