Firebase allow read, write: if true wyjaśnione: co robi i jak to naprawić

Składnia, linia po linii

Kompletny dokument reguł trybu testowego Firestore to sześć linii:

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

Zdekodowane:

• rules_version = '2'; wybiera silnik reguł v2 (aktualny). Starsze reguły v1 są przestarzałe.
• service cloud.firestore ogranicza blok do Firestore. Realtime Database używa innej składni opartej na JSON; Cloud Storage używa service firebase.storage.
• match /databases/{database}/documents wiąże specjalną bazę danych (default) (większość projektów ma tylko jedną).
• match /{document=**} to rekurencyjny wieloznacznik. ** pasuje do dowolnej ścieżki o dowolnej głębokości. W połączeniu z {document} przechwytuje każdy dokument w każdej kolekcji — pojedyncza klauzula match zarządzająca całą bazą danych.
• allow read, write: if true; to ciało reguły. Zarówno read, jak i write są dozwolone; warunek if true jest, cóż, zawsze prawdziwy. read obejmuje operacje get i list; write obejmuje create, update i delete.

Efekt netto: każdy klient z identyfikatorem projektu Firebase i odpowiednim SDK może odczytywać lub zapisywać dowolny dokument w dowolnej kolekcji. Uwierzytelnianie nie jest wymagane. Limity szybkości nie są wymuszane.

Dlaczego Firebase wysyła to jako domyślne

Firebase chce, abyś kodował w pierwsze 30 sekund po utworzeniu projektu. Alternatywa — zmuszenie Cię do napisania poprawnej reguły, zanim jakikolwiek odczyt lub zapis zadziała — zablokowałaby onboarding. Więc Console oferuje dwie opcje podczas tworzenia bazy danych: Tryb produkcyjny (odrzucaj wszystko, ty piszesz reguły) lub Tryb testowy (pozwalaj na wszystko przez 30 dni). Większość programistów klika tryb testowy, a następnie zapomina go ponownie odwiedzić. Starsze projekty miały 30-dniowy zegar; aktualne projekty mają nieokreśloną regułę if true bez automatycznego wygaśnięcia.

Strukturalny problem: narzędzia kodowania AI trenują na dokumentacji, samouczkach i odpowiedziach Stack Overflow pokazujących reguły trybu testowego. Kiedy pytasz Cursor lub Claude Code „jak skonfigurować Firebase", odpowiedź często zawiera dokładny blok allow read, write: if true, tak jakby to była reguła produkcyjna. AI nie wie — i nie jest skłaniane do wiedzy — że ta reguła nie jest bezpieczna dla produkcji.

Co widzi atakujący

Konkretnie, atakujący, który zna identyfikator Twojego projektu Firebase (możliwy do wyodrębnienia z pakietu dowolnej wdrożonej aplikacji w 30 sekund) i uruchamia poniższe, może wymienić każdy dokument w każdej kolekcji:

Pojedyncze nieuwierzytelnione żądanie curl wystarcza, aby wyliczyć każdą kolekcję. Zobacz wyróżniony blok poniżej.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Odpowiedź to pełna lista kolekcji najwyższego poziomu. Dla każdej kolekcji drugie żądanie zwraca dokumenty. Na tej ścieżce nie ma limitu szybkości, ponieważ reguły if true akceptują anonimowy ruch. Widzieliśmy bazy danych Firebase z milionami dokumentów wyliczonych w mniej niż godzinę.

Na ścieżce zapisu: pojedyncze POST z {fields} tworzy nowy dokument. Atakujący mogą zanieczyścić Twoje kolekcje śmieciami, oszpecić strony skierowane do użytkowników, które odczytują z Firestore, lub używać Twojej bazy danych jako darmowego brokera wiadomości — Twój rachunek za użytkowanie gwałtownie rośnie, badasz, a rachunek wyjaśnia problem.

Cztery zamienniki bezpieczne dla produkcji

Wybierz zamiennik pasujący do modelu danych Twojej aplikacji. Wszystkie cztery zakładają, że masz uwierzytelnianie użytkownika (Firebase Auth lub dowolny dostawca, który wystawia token ID Firebase):

Opcja 1: Dokumenty należące do użytkownika

Najczęstszy wzorzec SaaS. Dokumenty żyją pod /users/{userId}/... i tylko właściciel może ich dotykać. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Opcja 2: Pole właściciela w każdym dokumencie

Kiedy dokumenty żyją w płaskich kolekcjach (nie zagnieżdżone pod identyfikatorem użytkownika), przechowuj pole owner_uid i sprawdzaj je. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Opcja 3: Izolacja organizacji wielofirmowej

Dla B2B SaaS z danymi w zakresie org. Przechowuj pole org_id w każdym dokumencie i sprawdzaj je wobec niestandardowego roszczenia użytkownika. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Wymaga ustawienia niestandardowego roszczenia podczas rejestracji przez Firebase Admin SDK.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Opcja 4: Publiczna zawartość tylko do odczytu

Dla treści marketingowych, profili publicznych, katalogów produktów — wszystkiego, co jest naprawdę publicznie odczytywalne, ale zapisywalne tylko przez administratora. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Niestandardowe roszczenie admin jest ustawiane tylko na kontach administratora.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Szybkie zapytanie audytowe

Przed naprawą sprawdź, czy if true jest faktycznie aktywny. Otwórz Firebase Console → Firestore → Rules i wyszukaj if true. Jeśli znajdziesz go gdziekolwiek poza komentarzem, masz znalezisko otwartej reguły. Symulator reguł w tym samym interfejsie pozwala odtworzyć żądanie atakującego lokalnie — wklej anonimowe GET /users/somebody i potwierdź, że symulator zwraca Allowed.

Zewnętrzne potwierdzenie: uruchom skanowanie FixVibe wobec swojego produkcyjnego URL. Kontrola baas.firebase-rules sondy Twoje reguły Firestore, Realtime Database i Storage i zgłasza to samo znalezisko, które odkryłby atakujący — niezależnie od tego, co pokazuje Firebase Console.

Często zadawane pytania

Następne kroki

Uruchom skanowanie FixVibe wobec swojego produkcyjnego URL — kontrola baas.firebase-rules potwierdza, czy if true jest obecnie możliwy do wykorzystania z publicznego internetu. Dla mechaniki skanera i równoległych wykryć dla Realtime Database i Storage zobacz Skaner reguł Firebase. Dla równoważnej klasy błędnej konfiguracji w Supabase przeczytaj Skaner Supabase RLS.