Skaner reguł Firebase: znajdź otwarte reguły Firestore, Realtime Database i Storage

Jak skaner znajduje otwarte reguły Firebase

Usługi Firebase ujawniają dobrze znane, przewidywalne kształty URL. Skaner bez poświadczeń może sondować każdą z nich i obserwować, czy anonimowe odczyty się udają. Kontrola FixVibe baas.firebase-rules działa w trzech niezależnych sondach — po jednej na usługę Firebase:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. Skaner sondy https://[project-id]-default-rtdb.firebaseio.com/.json. Jeśli korzeń jest odczytywalny anonimowo, odpowiedź to całe drzewo bazy danych jako JSON. Bardziej konserwatywny test wysyła zapytanie .json?shallow=true, które zwraca tylko klucze najwyższego poziomu — znalezisko w obu przypadkach.
• Cloud Storage. Skaner wysyła zapytanie https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Jeśli odpowiedź listuje nazwy plików bez uwierzytelnienia, kosz jest anonimowo wyświetlalny. Wyświetlalne magazyny są znaleziskiem nawet wtedy, gdy poszczególne pobrania plików są odrzucane — atakujący wyliczają kosz, aby znaleźć zgadywalne nazwy plików.

Jak naprawdę wygląda pułapka trybu testowego

Dokumentacja szybkiego startu Firebase zawiera jeden z najbardziej kopiowanych bloków reguł w internecie:

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

Firebase dodawał kiedyś automatyczne 30-dniowe wygaśnięcie do tych reguł. To się zmieniło: dzisiaj reguły trwają wiecznie, chyba że programista je zastąpi. Narzędzia kodowania AI — trenowane na latach dokumentacji zawierającej blok trybu testowego — często emitują go dosłownie i mówią programiście „to jest Twoja reguła bezpieczeństwa". Nie jest.

Inne warianty, które pojawiają się w produkcji, ale są równie permisywne:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• Wariant ze znacznikiem czasu w przyszłości: reguła, która pozwala na wszystko do daty daleko w przyszłości. Nigdy efektywnie nie wygasa (zobacz wyróżniony blok powyżej).
• allow read: if true; allow write: if request.auth != null; — publiczne odczyty, każdy uwierzytelniony użytkownik może pisać.
• allow read, write: if request.auth != null; — każdy zalogowany użytkownik może czytać lub zapisywać dowolny dokument, w tym dane innych użytkowników.

Co zrobić, gdy skaner znajdzie otwartą regułę

Otwarte reguły Firebase są nagłą sytuacją środowiska wykonawczego. Naprawa ma ten sam kształt we wszystkich trzech usługach: ogranicz każdą regułę do request.auth.uid wobec jawnego pola właściciela. Każda usługa ma własną składnię reguł:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Powiązanie segmentu ścieżki {userId} staje się jedynym dokumentem, którego użytkownik może dotknąć.

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Konwencja: przechowuj pliki pod users/[uid]/[filename] i pozwól, aby ścieżka wymuszała własność.

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

Wdrażaj reguły przez Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Zweryfikuj, że nowe reguły są w produkcji, ponownie uruchamiając skanowanie FixVibe — znalezisko baas.firebase-rules powinno zniknąć.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Jak to się porównuje do wbudowanych narzędzi Firebase

Firebase Console pokazuje aktualne reguły, ale nie kontroluje ich wobec zachowania środowiska wykonawczego. Symulator reguł Firebase pozwala testować logikę reguł wobec syntetycznych żądań — przydatne, ale lokalne. Żadne narzędzie nie mówi Ci, co Twoje produkcyjne reguły faktycznie zwracają anonimowemu atakującemu w publicznym internecie. Zewnętrzny skaner taki jak FixVibe (lub Burp Suite z ręczną konfiguracją) to jedyna rzecz, która sondy z tego samego kąta, co atakujący. Własny App Check Google łagodzi nadużycia, ale nie zastępuje poprawnie ograniczonych reguł.

Często zadawane pytania

Następne kroki

Uruchom bezpłatne skanowanie FixVibe wobec swojego produkcyjnego URL — kontrola baas.firebase-rules jest dostarczana w każdym planie i flaguje otwarte reguły w Firestore, Realtime Database i Cloud Storage. Dla głębszego wyjaśnienia konkretnie wzorca allow read, write: if true zobacz Firebase allow read, write: if true wyjaśnione. Dla widoku parasolowego obejmującego Supabase, Firebase, Clerk i Auth0 przeczytaj Skaner błędnych konfiguracji BaaS.