Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Unikaj niezabezpieczonych reguł

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

Jeśli otrzymasz alert, ż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ć obecne Security Rules, użyj interfejsu wiersza poleceń Firebase lub konsoli Firebase. Aby uniknąć przypadkowego zastąpienia aktualizacji, edytuj reguły zawsze w ten sam sposób. Jeśli nie masz pewności czy zdefiniowane lokalnie reguły odzwierciedlają najnowsze aktualizacje, w konsoli Firebase zawsze wyświetla się najnowsza wdrożona wersja Firebase Security Rules.

Aby uzyskać dostęp do reguł w konsoli Firebase, wybierz projekt, a następnie kliknij Realtime Database, Cloud Firestore lub Storage. Gdy znajdziesz się w odpowiedniej bazie danych lub zasobniku, kliknij Reguły.

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

Informacje o Firebase Security Rules

Firebase Security Rules chronią Twoje dane przed złośliwymi użytkownikami. Gdy tworzysz 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). Podczas programowania możesz chcieć używać bardziej otwartej konfiguracji, ale przed wdrożeniem aplikacji poświęć czas na prawidłowe skonfigurowanie reguł i zabezpieczenie danych.

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

Typowe scenariusze z niebezpiecznymi regułami

Security Rules które mogły zostać skonfigurowane domyślnie lub podczas początkowego tworzenia aplikacji, 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 projektu w Firebase mogłeś(-aś) ustawić reguły tak, aby podczas programowania zezwalały na otwarty dostęp. Możesz myśleć, że tylko Ty używasz aplikacji, ale jeśli ją wdrożysz, będzie 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 ukraść, zmodyfikować lub usunąć dane.

Nie zalecamy: 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 mają sens w przypadku Twojej 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 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.

Nie zalecamy: każdy zalogowany użytkownik ma uprawnienia 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 określonych 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 "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 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"
      }
    }
  }
}

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 dziedziczone reguły

Realtime Database Security Rules są kaskadowe, a reguły na płytszych ścieżkach nadrzędnych zastępują reguły w głębszych węzłach podrzędnych. Gdy piszesz regułę w węźle podrzędnym, pamiętaj, że może ona tylko przyznawać dodatkowe uprawnienia. Nie możesz ograniczyć ani cofnąć dostępu do danych na głębszej ścieżce w bazie danych.

Nie zalecamy: doprecyzowywanie reguł na ś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: pisz reguły na ścieżkach nadrzędnych które są szerokie, i przyznawaj bardziej szczegółowe uprawnienia na ścieżkach podrzędnych Jeśli potrzebujesz większej szczegółowości dostępu do danych, zachowaj szczegółowe reguły. Więcej informacji o kaskadowych Realtime Database Security Rules znajdziesz w Podstawowa składnia Realtime Database Security Rules.

Zamknięty dostęp

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:

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ł, gdy chcesz używać Cloud Firestore lub Realtime Database 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.

Testowanie Cloud Firestore Security Rules

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

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

Unikaj niezabezpieczonych reguł Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Dostęp do Firebase Security Rules

Informacje o Firebase Security Rules

Typowe scenariusze z niebezpiecznymi regułami

Otwarty dostęp

Cloud Firestore

Realtime Database

Cloud Storage

Cloud Firestore

Tylko właściciel treści

Mieszany dostęp publiczny i prywatny

Realtime Database

Tylko właściciel treści

Mieszany dostęp publiczny i prywatny

Cloud Storage

Tylko właściciel treści

Mieszany dostęp publiczny i prywatny

Dostęp dla każdego uwierzytelnionego użytkownika

Cloud Firestore

Realtime Database

Cloud Storage

Cloud Firestore

Dostęp na podstawie roli

Dostęp na podstawie atrybutu

Mieszany dostęp publiczny i prywatny

Realtime Database

Tylko właściciel treści

Dostęp ograniczony ścieżką

Mieszany dostęp publiczny i prywatny

Cloud Storage

Dostęp na podstawie grupy

Tylko właściciel treści

Mieszany dostęp publiczny i prywatny

(Realtime Database) Nieprawidłowo dziedziczone reguły

Zamknięty dostęp

Cloud Firestore

Realtime Database

Cloud Storage

Testowanie Cloud Firestore Security Rules

Unikaj niezabezpieczonych reguł