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ć te problemy, modyfikując i testując swoje Cloud Firestore Security Rules.

Aby wyświetlić obecne 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 niebezpiecznymi 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. Zadbaj o odpowiednie zabezpieczenie danych użytkowników unikając tych typowych błędów.

Otwarty dostęp

Podczas konfigurowania Cloud Firestore mogłeś ustawić reguły, które podczas programowania zezwalają na otwarty dostęp. 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 weryfikacyjnego. 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ł, gdy 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 specyficzne dla 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ł.