Unikaj niepewnych zasad

Skorzystaj z tego przewodnika, aby zrozumieć typowe luki w konfiguracjach Reguł bezpieczeństwa Firebase, przejrzeć i lepiej zabezpieczyć własne reguły oraz przetestować zmiany przed ich wdrożeniem.

Jeśli otrzymasz powiadomienie, że Twoje dane nie są odpowiednio zabezpieczone, przejrzyj często popełniane błędy i zaktualizuj wszelkie podatne reguły.

Uzyskaj dostęp do reguł bezpieczeństwa Firebase

Aby wyświetlić istniejące reguły, użyj interfejsu wiersza polecenia Firebase lub konsoli Firebase. Upewnij się, że edytujesz swoje reguły przy użyciu tej samej metody, konsekwentnie, aby uniknąć omyłkowego nadpisania aktualizacji. Jeśli nie masz pewności, czy Twoje reguły zdefiniowane lokalnie odzwierciedlają najnowsze aktualizacje, konsola Firebase zawsze pokazuje najnowszą wdrożoną wersję Reguł bezpieczeństwa Firebase.

Aby uzyskać dostęp do reguł z konsoli Firebase , wybierz swój projekt, a następnie przejdź do opcji Baza danych czasu rzeczywistego , Cloud Firestore lub Storage . Kliknij Reguły , gdy znajdziesz się we właściwej bazie danych lub zasobniku pamięci.

Aby uzyskać dostęp do swoich reguł z Firebase CLI, przejdź do pliku reguł zapisanego w pliku firebase.json .

Zapoznaj się z regułami bezpieczeństwa Firebase

Reguły bezpieczeństwa Firebase chronią Twoje dane przed złośliwymi użytkownikami. Tworząc instancję bazy danych lub zasobnik Cloud Storage w konsoli Firebase, możesz odmówić dostępu wszystkim użytkownikom ( tryb zablokowany ) lub przyznać dostęp wszystkim użytkownikom ( tryb testowy ). Chociaż podczas opracowywania możesz potrzebować bardziej otwartej konfiguracji, pamiętaj, aby poświęcić trochę czasu na prawidłowe skonfigurowanie reguł i zabezpieczenie danych przed wdrożeniem aplikacji.

Tworząc aplikację i testując różne konfiguracje reguł, użyj jednego z lokalnych emulatorów Firebase, aby uruchomić aplikację w lokalnym środowisku programistycznym.

Typowe scenariusze z niepewnymi regułami

Reguły, które mogłeś skonfigurować domyślnie lub podczas początkowej pracy nad rozwojem aplikacji, powinny zostać przejrzane i zaktualizowane przed wdrożeniem aplikacji. Upewnij się, że odpowiednio zabezpieczasz dane użytkowników, unikając następujących typowych pułapek.

Otwarty dostęp

Podczas konfigurowania projektu Firebase mogłeś ustawić reguły zezwalające na otwarty dostęp podczas programowania. Możesz myśleć, że jesteś jedyną osobą korzystającą z aplikacji, ale jeśli ją wdrożyłeś, jest 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 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;
    }
  }
}

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

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      allow read, write: if request.auth != null && request.auth.uid == request.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 read: if true
      allow write: if request.auth != null && request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

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

{
  // 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"
    }
  }
}
    

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

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 Reguły sprawdzają, czy użytkownik jest zalogowany, ale nie ograniczają dalej dostępu na podstawie tego uwierzytelnienia. Jeśli jedna z Twoich reguł obejmuje 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.uid != null;
    }
  }
}

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

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

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

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

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid"
      }
    }
  }
}
    

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

{
  // 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"
    }
  }
}
    

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

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

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

(Baza danych czasu rzeczywistego) Niewłaściwie odziedziczone reguły

Kaskada reguł bezpieczeństwa bazy danych w czasie rzeczywistym, z regułami na płytszych ścieżkach nadrzędnych nadrzędnych w głębszych węzłach podrzędnych. Kiedy piszesz regułę w węźle podrzędnym, pamiętaj, że może ona nadawać tylko dodatkowe uprawnienia. Nie możesz zawęzić ani odwołać dostępu do danych na głębszej ścieżce w bazie danych.

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

Dostęp zamknięty

Podczas opracowywania aplikacji innym powszechnym podejściem 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;
    }
  }
}

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

// 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. Skorzystaj z tych reguł, jeśli zamierzasz używać Cloud Firestore lub Realtime Database jako zaplecza obsługującego tylko serwer w połączeniu z Firebase Admin SDK. Chociaż jest to bezpieczne, należy przetestować, czy klienci aplikacji mogą prawidłowo pobierać dane.

Dowiedz się więcej o regułach bezpieczeństwa Cloud Firestore i sposobie ich działania w artykule Pierwsze kroki z regułami bezpieczeństwa Cloud Firestore .

Przetestuj swoje reguły bezpieczeństwa Cloud Firestore

Aby sprawdzić zachowanie aplikacji i zweryfikować konfiguracje Reguł bezpieczeństwa Cloud Firestore, użyj emulatora Firebase . Użyj emulatora Cloud Firestore, aby uruchomić i zautomatyzować testy jednostkowe w środowisku lokalnym przed wdrożeniem jakichkolwiek zmian.

Aby szybko zweryfikować reguły bezpieczeństwa Firebase w konsoli Firebase, użyj Symulatora reguł Firebase .