Unikaj niezabezpieczonych reguł

Z tego przewodnika dowiesz się, jakie są typowe luki w zabezpieczeniach Firebase Security Ruleskonfiguracji. Pozwoli Ci to sprawdzić i lepiej zabezpieczyć własne reguły oraz przetestować zmiany przed ich wdrożeniem.

Jeśli otrzymasz alert o tym, że Twoje dane nie są odpowiednio zabezpieczone, sprawdź te często popełniane błędy i zaktualizuj wszystkie podatne na ataki reguły.

Dostęp do Firebase Security Rules

Aby wyświetlić istniejące Rules, użyj interfejsu wiersza poleceń Firebase lub konsoli Firebase. Aby uniknąć przypadkowego zastąpienia aktualizacji, edytuj reguły zawsze tą samą metodą. Jeśli nie masz pewności, czy zdefiniowane lokalnie reguły odzwierciedlają najnowsze aktualizacje, w konsoli Firebase zawsze zobaczysz ostatnio wdrożoną wersję Firebase Security Rules.

Aby uzyskać dostęp do reguł w Firebasekonsoli, wybierz projekt, a następnie kliknij Realtime Database, Cloud Firestore lub Storage. Gdy otworzysz odpowiednią bazę danych lub zasobnik pamięci, kliknij Reguły.

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

Zrozumienie Firebase Security Rules

Firebase Security Rules chronić dane przed złośliwymi użytkownikami; Podczas tworzenia instancji bazy danych lub Cloud Storage kosza w Firebase konsoli możesz odmówić dostępu wszystkim użytkownikom (tryb zablokowany) lub przyznać dostęp wszystkim użytkownikom (tryb testowy). Podczas tworzenia aplikacji możesz chcieć mieć bardziej otwartą konfigurację, ale przed jej wdrożeniem poświęć czas na prawidłowe skonfigurowanie reguł i zabezpieczenie danych.

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

Typowe scenariusze z niebezpiecznymi regułami

Rules, które mogły zostać skonfigurowane domyślnie lub podczas początkowych prac nad aplikacją, 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 projektu Firebase mogłeś(-aś) ustawić reguły, które zezwalają na otwarty dostęp w trakcie programowania. Może Ci się wydawać, że tylko Ty korzystasz z aplikacji, ale jeśli została ona wdrożona, jest dostępna w internecie. Jeśli nie uwierzytelniasz użytkowników i nie konfigurujesz reguł zabezpieczeń, każdy, kto odgadnie identyfikator Twojego projektu, może wykradać, modyfikować lub usuwać dane.

Nie zalecane: uprawnienia do odczytu i zapisu dla 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 using 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 ograniczające uprawnienia do odczytu i zapisu. Twórz reguły, które pasują do hierarchii danych. Jednym z popularnych rozwiązań tego problemu jest zabezpieczenie oparte na użytkownikach z Firebase Authentication. Dowiedz się więcej o uwierzytelnianiu użytkowników za pomocą reguł. Cloud Firestore Tylko właściciel 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; } } } Mieszany dostęp 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; } } } Realtime Database Tylko właściciel 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" } } } } Mieszany dostęp publiczny i prywatny { // 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ściciel 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>/file.txt" match /user/{userId}/{fileName} { allow read, write: if request.auth.uid == userId; } } } Mieszany dostęp publiczny i prywatny service firebase.storage { match /b/{bucket}/o { // Files look like: "user/<UID>/file.txt" match /user/{userId}/{fileName} { allow read; allow write: if request.auth.uid == userId; } } }

Dostęp dla każdego uwierzytelnionego użytkownika

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

Nie zalecane: każdy zalogowany użytkownik ma dostęp do odczytu i zapisu w całej bazie 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 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 "administrator" attribute set // to "true" grants write access to data service cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true; allow read: true; } } } Mieszany dostęp 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 } } } Realtime Database Tylko właściciel 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 wyznaczony przez ś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" } } } } Mieszany dostęp publiczny i prywatny { // 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 `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ściciel 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>/file.txt" match /user/{userId}/{fileName} { allow read, write: if request.auth.uid == userId; } } } Mieszany dostęp publiczny i prywatny service firebase.storage { match /b/{bucket}/o { // Files look like: "user/<UID>/file.txt" match /user/{userId}/{fileName} { 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 płytszych ścieżkach nadrzędnych zastępują reguły na głębszych węzłach podrzędnych. Pamiętaj, że reguła zapisana w węźle podrzędnym może tylko przyznawać dodatkowe uprawnienia. Nie możesz zawęzić ani cofnąć dostępu do danych na głębszej ścieżce w bazie danych.

Niezalecane: doprecyzowywanie reguł w przypadku ścieżek 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: utwórz reguły w przypadku ścieżek nadrzędnych, które są ogólne, i przyznaj bardziej szczegółowe uprawnienia w przypadku ścieżek podrzędnych. Jeśli potrzebujesz bardziej szczegółowego dostępu do danych, zachowaj szczegółowe reguły. Dowiedz się więcej o kaskadowym Realtime Database Security Rules w podstawowej składni Realtime Database Security Rules.

Dostęp zamknięty

Podczas tworzenia aplikacji często stosuje się też inne podejście, które polega na zabezpieczeniu 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:

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 mogą uzyskiwać dostęp do Twojej bazy danych. Używaj tych reguł, jeśli zamierzasz używać Cloud Firestore lub Realtime Database jako backendu tylko po stronie serwera w połączeniu z pakietem Firebase Admin SDK. Chociaż jest bezpieczne, warto sprawdzić, czy klienci aplikacji mogą prawidłowo pobierać dane.

Dowiedz się więcej o Cloud Firestore Security Rules i o tym, jak działają w pierwszych krokach z Cloud Firestore Security Rules.

Testowanie Cloud Firestore Security Rules

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

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