Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Podstawowe zasady bezpieczeństwa

Reguły zabezpieczeń Firebase umożliwiają kontrolę dostępu do przechowywanych danych. Elastyczna składnia reguł oznacza, że ​​możesz tworzyć reguły, które pasują do wszystkiego, od wszystkich zapisów do całej bazy danych po operacje na określonym dokumencie.

W tym przewodniku opisano niektóre z bardziej podstawowych przypadków użycia, które możesz chcieć wdrożyć podczas konfigurowania aplikacji i zabezpieczania danych. Jednak przed rozpoczęciem pisania reguł, może chcesz dowiedzieć się więcej o języku są one napisane i ich zachowań .

Aby uzyskać dostęp i zaktualizować zasady, należy wykonać czynności opisane w zarządzaniu i wdrażają Firebase zasad bezpieczeństwa .

Domyślne zasady: tryb zablokowany

Podczas tworzenia bazy danych lub pamięci instancji w konsoli Firebase, można wybrać, czy reguły zabezpieczeń Firebase ograniczyć dostęp do danych (tryb Zablokowane) lub pozwalają każdemu dostępu (tryb testowy). W Cloud FireStore i Realtime Database, zasady domyślne dla trybu zablokowane odmówić dostępu do wszystkich użytkowników. W Cloud Storage tylko uwierzytelnieni użytkownicy mają dostęp do zasobników pamięci.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Baza danych czasu rzeczywistego

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

Magazyn w chmurze

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Zasady rozwoju środowiska

Podczas pracy nad aplikacją możesz chcieć stosunkowo otwartego lub nieograniczonego dostępu do swoich danych. Pamiętaj tylko o zaktualizowaniu reguł przed wdrożeniem aplikacji w środowisku produkcyjnym. Należy również pamiętać, że jeśli wdrożyć aplikację, jest publicznie dostępna - nawet jeśli nie uruchomił go.

Pamiętaj, że Firebase umożliwia klientom bezpośredni dostęp do Twoich danych, a Reguły zabezpieczeń Firebase są jedynym zabezpieczeniem blokującym dostęp złośliwym użytkownikom. Definiowanie reguł oddzielnie od logiki produktu ma wiele zalet: klienci nie są odpowiedzialni za egzekwowanie bezpieczeństwa, błędne implementacje nie narażają Twoich danych, a co najważniejsze, nie polegasz na serwerze pośredniczącym w celu ochrony danych ze świata.

Wszyscy uwierzytelnieni użytkownicy

Chociaż nie zalecamy udostępniania swoich danych żadnemu zalogowanemu użytkownikowi, przydatne może być ustawienie dostępu dla dowolnego uwierzytelnionego użytkownika podczas tworzenia aplikacji.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Baza danych czasu rzeczywistego

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

Magazyn w chmurze

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Zasady gotowe do produkcji

Przygotowując się do wdrożenia aplikacji, upewnij się, że Twoje dane są chronione i że dostęp jest odpowiednio przyznawany użytkownikom. Dźwignia Authentication skonfigurować dostęp użytkownika opartego i czytać bezpośrednio z bazy danych, aby skonfigurować dane opartych dostępu.

Rozważ pisanie reguł podczas strukturyzowania danych, ponieważ sposób ich konfigurowania ma wpływ na to, jak ograniczasz dostęp do danych na różnych ścieżkach.

Dostęp tylko dla właściciela treści

Reguły te ograniczają dostęp tylko do uwierzytelnionego właściciela treści. Dane mogą być odczytywane i zapisywane tylko przez jednego użytkownika, a ścieżka danych zawiera identyfikator użytkownika.

Gdy ta zasada działa: Zasada ta działa dobrze, jeśli dane są autonomicznych przez użytkownika - jeśli tylko użytkownik, który musi uzyskać dostęp do danych jest ten sam użytkownik, który utworzył dane.

Gdy ta zasada nie działa: Ten zestaw reguł nie działa, gdy wielu użytkowników trzeba pisać lub czytać te same dane - użytkownicy będą nadpisanie danych lub nie być w stanie uzyskać dostęp do danych utworzonych oni.

Aby skonfigurować tę regułę: Utwórz regułę potwierdza użytkownik żąda dostępu do odczytu lub zapisu danych jest użytkownik, który jest właścicielem tych danych.

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{documents=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

Baza danych czasu rzeczywistego

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

Magazyn w chmurze

// 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 != null && request.auth.uid == userId;
    }
  }
}

Mieszany dostęp publiczny i prywatny

Ta reguła umożliwia każdemu odczytanie zestawu danych, ale ogranicza możliwość tworzenia lub modyfikowania danych w danej ścieżce tylko do uwierzytelnionego właściciela treści.

Gdy ta zasada działa: Zasada ta działa również w przypadku aplikacji, które wymagają publicznie elementy czytelne, ale trzeba ograniczyć dostęp do edycji właścicieli tych elementów. Na przykład aplikacja do czatu lub blog.

Gdy ta zasada nie działa: Podobnie jak w przypadku zawartości-właściciel tylko regułę, ten zestaw reguł nie działa, gdy wielu użytkowników należy edytować te same dane. Użytkownicy ostatecznie nadpiszą swoje dane.

Aby skonfigurować tę regułę: Utwórz regułę, która umożliwia dostęp do odczytu dla wszystkich użytkowników (lub wszystkich uwierzytelnionych użytkowników) i potwierdza dane pisanie użytkownik jest właścicielem.

Cloud Firestore

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 create: if request.auth.uid == request.resource.data.author_uid;
      allow update, delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

Baza danych czasu rzeczywistego

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

Magazyn w chmurze

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 oparty na atrybutach i rolach

Aby ta reguła działała, musisz zdefiniować i przypisać atrybuty do użytkowników w swoich danych. Reguły zabezpieczeń Firebase porównują żądanie z danymi z bazy danych lub metadanymi pliku, aby potwierdzić lub odmówić dostępu.

Gdy ta zasada działa: Jeśli przypisanie roli użytkowników, zasada ta ułatwia dostęp granicznej na podstawie ról lub określonych grup użytkowników. Na przykład, jeśli zapisałeś oceny, możesz przypisać różne poziomy dostępu do grupy „uczniowie” (tylko przeczytaj ich treść), grupie „nauczyciele” (czytaj i pisz w swoim temacie) oraz grupie „dyrekcja” (czytaj cała zawartość).

Gdy ta zasada nie działa: w czasie rzeczywistym bazy danych i Cloud Storage, twoje zasady nie może wykorzystać get() metodę, że zasady Chmura FireStore mogą zawierać. W związku z tym musisz uporządkować bazę danych lub metadane pliku, aby odzwierciedlić atrybuty, których używasz w swoich regułach.

Aby skonfigurować tę regułę: w Cloud FireStore, to pole w dokumentach swoich użytkowników, które można odczytać, a następnie zorganizuj swoją regułę do czytania tej dziedzinie i warunkowo udzielić dostępu. W Bazie danych czasu rzeczywistego utwórz ścieżkę danych, która definiuje użytkowników aplikacji i przydziela im rolę w węźle podrzędnym.

Można również skonfigurować niestandardowe żądania uwierzytelniania i następnie pobrać te informacje z auth.token zmienna we wszelkich zasad bezpieczeństwa Firebase.

Atrybuty i role zdefiniowane przez dane

Te reguły działają tylko w Cloud Firestore i Bazie danych czasu rzeczywistego.

Cloud Firestore

Pamiętaj, że za każdym razem, gdy Twoje reguły obejmują odczyt, tak jak w poniższych regułach, płacisz za operację odczytu w Cloud Firestore.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    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"
   }
  }
}

Baza danych czasu rzeczywistego

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() == 'admin'",
        ".read": true
      }
    }
  }
}

Atrybuty i role niestandardowych roszczeń

Aby realizować te zasady, skonfigurować niestandardowe żądania uwierzytelniania Firebase a następnie wykorzystać roszczeń w swoich zasadach.

Cloud Firestore

Pamiętaj, że za każdym razem, gdy Twoje reguły obejmują odczyt, tak jak w poniższych regułach, płacisz za operację odczytu w Cloud Firestore.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

Baza danych czasu rzeczywistego

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to leverage
        ".write": "auth.uid != null && auth.token.writer == true",
        ".read": "auth.uid != null && auth.token.reader == true"
      }
    }
  }
}

Magazyn w chmurze

service firebase.storage {
  // 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;
  }
}