Unikaj niezabezpieczonych reguł

Z tego przewodnika dowiesz się, jakie częste luki w zabezpieczeniach występują w konfiguracjach Firebase Security Rules, jak sprawdzić i poprawić zabezpieczenia własnych reguł oraz jak przetestować zmiany przed ich wdrożeniem.

Jeśli otrzymasz alert, że Twoje dane nie są odpowiednio zabezpieczone, sprawdzić te typowe błędy i zaktualizować reguły z lukami w zabezpieczeniach.

Uzyskaj dostęp do urządzenia Firebase Security Rules

Aby wyświetlić obecne Rules, użyj interfejsu wiersza poleceń Firebase lub Firebase. Pamiętaj, aby w ten sam sposób edytować reguły, konsekwentnie, aby uniknąć przypadkowego zastępowania aktualizacji. Jeśli nie masz pewności czy reguły zdefiniowane lokalnie odzwierciedlają najnowsze aktualizacje, konsola zawsze wyświetla ostatnio wdrożoną wersję systemu Firebase Security Rules.

Aby uzyskać dostęp do reguł w konsoli Firebase, wybierz projekt, a potem przejdź do Realtime Database, Cloud Firestore lub Przechowywanie danych. Gdy znajdziesz się w odpowiedniej bazie danych lub pojemniku magazynu, kliknij Reguły.

Aby uzyskać dostęp do reguł z poziomu interfejsu wiersza poleceń Firebase, otwórz reguł zanotowanych w pliku firebase.json.

Firebase Security Rules

Firebase Security Rules chronić dane przed złośliwymi użytkownikami. Podczas tworzenia bazy danych lub zasobnik Cloud Storage w konsoli Firebase, możesz odmówić dostępu wszystkim użytkownikom (tryb blokady) lub przyznać dostęp wszystkich użytkowników (tryb testowy). Podczas tworzenia aplikacji możesz chcieć użyć bardziej otwartej konfiguracji, ale pamiętaj, aby przed jej wdrożeniem odpowiednio skonfigurować reguły i zabezpieczyć dane.

Podczas tworzenia aplikacji i testowania różnych konfiguracji reguł używaj jednego z lokalnych emulatorów Firebase, aby uruchamiać aplikację w lokalnym środowisku programistycznym.

Typowe scenariusze dotyczące niepewnych reguł

Rules, które możesz skonfigurować domyślnie lub we własnym zakresie pracy nad Twoją aplikacją należy przejrzeć i zaktualizować przed wdrożeniem aplikacji. Zadbaj o prawidłowe zabezpieczenie użytkowników dane dzięki unikaniu tych typowych pułapek.

Otwarty dostęp

Podczas konfigurowania projektu Firebase mogłeś/mogłaś 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 jesteś uwierzytelnianie użytkowników i konfigurowanie reguł zabezpieczeń, a potem każdy, kto zgadnie identyfikator projektu może ukraść, zmodyfikować lub usunąć dane.

Niezalecane: uprawnienia do odczytu i zapisu w przypadku: wszystkich użytkowników. Cloud Firestore // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; } } } Realtime Database { // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. "rules": { ".read": true, ".write": true } } Cloud Storage // Anyone can read or write to the bucket, even non-users of your app. // Because it is shared with App Engine, this will also make // files uploaded via App Engine public. // Warning: This rule makes every file in your Cloud Storage bucket accessible to any user. // Apply caution before using it in production, since it means anyone // can overwrite all your files. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write; } } }

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 typowych rozwiązań z tym brakiem bezpieczeństwa są oparte na użytkownikach w Firebase Authentication. Więcej informacji o uwierzytelniania użytkowników za pomocą reguł. Cloud Firestore 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 nie jest ograniczony 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; } } } Realtime Database Tylko właściciele treści { "rules": { "some_path": { "$uid": { // Allow only authenticated content owners access to their data ".read": "auth !== null && auth.uid === $uid", ".write": "auth !== null && auth.uid === $uid" } } } } Dostęp publiczny i prywatny nie jest ograniczony { // Allow anyone to read data, but only authenticated content owners can // make changes to their data "rules": { "some_path/$uid": { ".read": true, // or ".read": "auth.uid !== null" for only authenticated users ".write": "auth.uid === $uid" } } } Cloud Storage Tylko właściciele treści // Grants a user access to a node matching their user ID service firebase.storage { match /b/{bucket}/o { // Files look like: "user/<UID>/path/to/file.txt" match /user/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } } Dostęp publiczny i prywatny nie jest ograniczony service firebase.storage { match /b/{bucket}/o { // Files look like: "user/<UID>/path/to/file.txt" match /user/{userId}/{allPaths=**} { allow read; allow write: if request.auth.uid == userId; } } }

Dostęp dla każdego uwierzytelnionego użytkownika

Czasami 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 przeczytał i uprawnienia do zapisu całej bazy danych. Cloud Firestore service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth.uid != null; } } } Realtime Database { "rules": { ".read": "auth.uid !== null", ".write": "auth.uid !== null" } } Cloud Storage // Only authenticated users can read or write to the bucket service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { 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 dodatkowo ograniczyć dostęp do określonych zbiorów danych dla konkretnych użytkowników. Dowiedz się więcej o różnych właściwościach uwierzytelniania. Cloud Firestore 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 get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader" allow write: if 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 atrybutu // 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 publiczny i prywatny nie jest ograniczony 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 } } } Realtime Database Tylko właściciele treści { "rules": { "some_path": { "$uid": { // Allow only authenticated content owners access to their data ".read": "auth.uid === $uid", ".write": "auth.uid === $uid" } } } } Dostęp ograniczony ścieżką { "rules": { "some_path/$uid": { ".write": "auth.uid === $uid", // Create a "public" subpath in your dataset "public": { ".read": true // or ".read": "auth.uid !== null" }, // Create a "private" subpath in your dataset "private": { ".read": "auth.uid === $uid" } } } } Dostęp publiczny i prywatny nie jest ograniczony { // Allow anyone to read data, but only authenticated content owners can // make changes to their data "rules": { "some_path/$uid": { ".read": true, // or ".read": "auth.uid !== null" for only authenticated users ".write": "auth.uid === $uid" } } } Cloud Storage Dostęp na podstawie grupy // Allow reads if the group ID in your token matches the file metadata's `owner` property // Allow writes if the group ID is in the user's custom token match /files/{groupId}/{fileName} { allow read: if resource.metadata.owner == request.auth.token.groupId; allow write: if request.auth.token.groupId == groupId; } Tylko właściciele treści // Grants a user access to a node matching their user ID service firebase.storage { match /b/{bucket}/o { // Files look like: "user/<UID>/path/to/file.txt" match /user/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } } Dostęp mieszany (publiczny i prywatny) service firebase.storage { match /b/{bucket}/o { // Files look like: "user/<UID>/path/to/file.txt" match /user/{userId}/{allPaths=**} { allow read; allow write: if request.auth.uid == userId; } } }

(Realtime Database) Nieprawidłowo odziedziczone reguły

Realtime Database Security Rules kaskadowo, przy czym reguły na krótszych ścieżkach nadrzędnych zastępują reguły na dłuższych ścieżkach podrzędnych. Pamiętaj, że reguła w węźle podrzędnym może przyznać tylko dodatkowe uprawnienia. Nie można zawęzić ani unieważnić na głębszą ścieżkę w bazie danych.

Niezalecane: doprecyzowywanie reguł w ścieżkach podrzędnych { "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { /* ignored, since read was allowed already */ ".read": false } } } }

Rozwiązanie: na ścieżkach nadrzędnych zapisz reguły o szerszym zakresie, a na ścieżkach podrzędnych nadaj bardziej szczegółowe uprawnienia. Jeśli Twoje potrzeby dotyczące dostępu do danych wymagają większej szczegółowości, zachowaj szczegółowość reguł. Dowiedz się więcej o umieszczaniu Realtime Database Security Rules w poziomie w podstawowej składni Realtime Database Security Rules.

Zamknięty dostęp

Podczas tworzenia aplikacji możesz też zadbać o to, aby Twoja aplikacja dostęp do danych będzie zablokowany. Zwykle oznacza to, że odczyt i zapis są wyłączone dostęp dla wszystkich użytkowników w następujący sposób:

Cloud Firestore

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Realtime Database

{
  "rules": {
    ".read": false,
    ".write": false
  }
}
    

Cloud Storage

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      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ć pakietu Cloud Firestore lub Realtime Database 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.

Testowanie Cloud Firestore Security Rules

Aby sprawdzić działanie aplikacji i sprawdzać konfiguracje Cloud Firestore Security Rules, użyj emulatora Firebase. Użyj funkcji Cloud Firestore emulatorowi do uruchamiania i automatyzacji testów jednostkowych w środowisku lokalnym przed wdrożeniem. żadnych zmian.

Aby szybko sprawdzić poprawność Firebase Security Rules w konsoli Firebase, użyj w symulatorze reguł Firebase.