Napraw niezabezpieczone reguły

Z tego przewodnika dowiesz się, jakie są typowe luki w zabezpieczeniach Cloud Firestore Security Rules konfiguracji, jak sprawdzić i lepiej zabezpieczyć własne reguły oraz jak przetestować zmiany przed ich wdrożeniem.

Aby uzyskać pomoc AI, skopiuj poniższy prompt do agenta kodowania AI (np. Gemini w Android Studio, Antigravity, Claude Code, Codex i Cursor). Możesz dostosować prompta i współpracować z agentem. Szczegółowe informacje o instalacji znajdziesz w artykule Umiejętności agenta Firebase.

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Firestore data.

Jeśli otrzymasz alert, że Cloud Firestore baza danych nie jest odpowiednio zabezpieczona, możesz usunąć luki w zabezpieczeniach, modyfikując i testując Cloud Firestore Security Rules.

Aby wyświetlić istniejące reguły zabezpieczeń, otwórz kartę Reguły w konsoli Firebase.

Poznaj swoje urządzenie Cloud Firestore Security Rules

Cloud Firestore Security Rules chronić dane przed złośliwymi użytkownikami; Domyślne reguły dla każdego wystąpienia Cloud Firestore utworzonego w konsoli Firebase odmawiają dostępu wszystkim użytkownikom. Aby rozwijać aplikację i uzyskać dostęp do bazy danych, musisz zmodyfikować te reguły. Możesz też rozważyć przyznanie ogólnego dostępu wszystkim użytkownikom w środowisku programistycznym. Zanim jednak wdrożysz aplikację w środowisku produkcyjnym, poświęć czas na prawidłowe skonfigurowanie reguł i zabezpieczenie danych.

Podczas tworzenia aplikacji i testowania różnych konfiguracji reguł używaj Cloud Firestoreemulatora, aby uruchamiać aplikację w lokalnym środowisku programistycznym.

Typowe scenariusze z niebezpiecznymi regułami

Cloud Firestore Security Rules, które mogły zostać skonfigurowane domyślnie lub podczas początkowych prac nad aplikacją z użyciem Cloud Firestore, 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 Cloud Firestore mogłeś(-aś) ustawić reguły, które zezwalają na otwarty dostęp w trakcie programowania. Może Ci się wydawać, że tylko Ty używasz 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ł bezpieczeństwa, każda osoba, która odgadnie identyfikator Twojego projektu, może ukraść, zmodyfikować lub usunąć dane.

Nie zalecane: uprawnienia do odczytu i zapisu dla wszystkich użytkowników.
// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}
Rozwiązanie: reguły ograniczające uprawnienia do odczytu i zapisu.

Twórz reguły, które pasują do 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ł.

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

Dostęp dla każdego uwierzytelnionego użytkownika

Czasami Cloud Firestore Security 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.
service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}
Rozwiązanie: ograniczenie dostępu 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 użytkowników w przypadku konkretnych zbiorów danych. Dowiedz się więcej o dodawaniu warunków bezpieczeństwa i dostępie na podstawie roli.

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 request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && 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 oparty na atrybutach

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

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

Dostęp dla niezweryfikowanych adresów e-mail

Czasami Cloud Firestore Security Rules sprawdź, czy adres e-mail użytkownika należy do konkretnej domeny. Chociaż jest to ogólnie dobra praktyka, adresy e-mail nie zawsze są weryfikowane podczas logowania, dopóki użytkownik nie wykona dodatkowego kroku po otrzymaniu e-maila weryfikacyjnego. Upewnij się, że sprawdzasz, czy adres e-mail należy do użytkownika.

Nie zalecane: każdy użytkownik może zalogować się za pomocą dowolnego adresu e-mail.
service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}
Rozwiązanie: ogranicz dostęp tylko do zweryfikowanych adresów e-mail.

Potwierdzanie adresów e-mail

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

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:

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

Pakiety Firebase Admin SDK i Cloud Functions nadal mogą uzyskiwać dostęp do Twojej bazy danych. Korzystaj z tych reguł, jeśli chcesz używać Cloud Firestore jako backendu tylko na serwerze w połączeniu z pakietem Firebase Admin SDK. Chociaż jest bezpieczny, 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.

Sprawdź aplikację Cloud Firestore Security Rules

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

Aby szybko przetestować zaktualizowane Cloud Firestore Security Rules w konsoli Firebase, użyj narzędzia Plac zabaw dla reguł.

  1. Aby otworzyć środowisko do testowania reguł, na karcie Reguły kliknij Środowisko do testowania reguł.
  2. W ustawieniach Placu zabaw dla reguł wybierz opcje testu, w tym:
    • Testowanie odczytów i zapisów
    • określona lokalizacja w bazie danych jako ścieżka;
    • Typ uwierzytelniania – nieuwierzytelniony, uwierzytelniony anonimowy użytkownik lub konkretny identyfikator użytkownika.
    • dane specyficzne dla dokumentu, do których odwołują się Twoje reguły (np. jeśli reguły wymagają obecności określonego pola przed zezwoleniem na zapis);
  3. Kliknij Wykonaj i sprawdź wyniki na banerze nad oknem reguł.