Firebase to ulubiony backend wielu aplikacji tworzonych przez AI: Lovable, Bolt czy Cursor podpinają go w kilka minut i masz uwierzytelnianie, bazę danych i pliki bez stawiania serwera. Problem w tym, że jego model bezpieczeństwa jest odwrotnością tego z tradycyjnego backendu. Tutaj przeglądarka rozmawia bezpośrednio z bazą danych, więc nie ma serwera, który filtruje żądania: reguły bezpieczeństwa są Twoją jedyną barierą, a jedna źle napisana reguła wystawia wszystkie dane na widok. Ten przewodnik omawia dziesięć najczęściej powtarzających się błędów, z błędną i poprawną regułą w każdym przypadku, i kończy się tym, jak sprawdzić to samodzielnie.
1. Reguły w trybie testowym, czyli co przychodzi potem
Przy tworzeniu bazy danych Firebase proponuje „tryb testowy": wszystko otwarte przez trzydzieści dni. Reguła wygląda tak:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2026, 11, 3);
}
}
}Do tej daty każdy, kto zna Twoje projectId (a jest ono w kodzie przeglądarki), może czytać i zapisywać całą bazę danych. A najgorsze przychodzi potem: po wygaśnięciu aplikacja przestaje działać, programista szuka szybkiego rozwiązania i zamienia datę na if true. Teraz dziura jest na stałe. Rozwiązaniem jest pisanie reguł per kolekcja od pierwszego dnia, opartych na tym, kim jest użytkownik i do kogo należy dokument.
2. allow read: if true na danych użytkowników
Są kolekcje, które mogą być publiczne (katalog produktów, posty na blogu). Ale allow read: if true na users, orders czy messages oznacza, że każdy może pobrać pełną listę. Poprawny sposób ochrony dokumentów per użytkownik:
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}Każdy użytkownik czyta i zapisuje tylko swój dokument. Dla danych współdzielonych przez kilka osób (zespół, projekt) zapisz listę członków w dokumencie i sprawdzaj ją w regule.
3. Mylenie „uwierzytelniony" z „autoryzowany"
Reguła allow read: if request.auth != null wygląda bezpiecznie i jest najczęstszym błędem. Mówi: każdy zalogowany użytkownik może czytać. Ale rejestracja w Twojej aplikacji jest darmowa i trwa dziesięć sekund, więc w praktyce to to samo co otwarte. Uwierzytelniony odpowiada na pytanie kim jesteś; autoryzowany na co możesz zobaczyć. Reguły muszą odpowiadać na to drugie.
4. Wrażliwe dane w czytelnych dokumentach
Publiczny profil z imieniem i awatarem jest rozsądny. Ten sam dokument z e-mailem, telefonem, adresem i tokenem dostępu już nie. Jeśli inni użytkownicy muszą widzieć część profilu, rozdziel publiczne od prywatnego na dwa dokumenty albo do podkolekcji private z ostrzejszymi regułami. To, czego nie ma w czytelnym dokumencie, nie może wyciec.
5. Myślenie, że konfiguracja Firebase to sekret
Obiekt z apiKey, authDomain i projectId trafia do przeglądarki z założenia: identyfikuje Twój projekt, niczego nie autoryzuje. Zobaczenie go w źródle to nie błąd i nie to trzeba ukrywać. Co natomiast trzeba zrobić z tym kluczem: ograniczyć go w konsoli Google Cloud do domen Twojej strony (ograniczenie po referrerze HTTP) i włączyć App Check, który wymaga, żeby żądania pochodziły z Twojej prawdziwej aplikacji, a nie ze skryptu.
6. Inne klucze są naprawdę sekretne
Poważny błąd jest inny: obok konfiguracji Firebase bundle niesie sekretny klucz Stripe, klucz OpenAI albo klucz usługi mailowej, bo „tak było łatwiej". Te klucze dają dostęp do pieniędzy i kont u osób trzecich. Ich miejsce to Cloud Function z sekretami w zmiennych środowiskowych, a przeglądarka wywołuje funkcję, nigdy usługę bezpośrednio. Szczegóły w sekrety, które Twoja aplikacja wycieka w przeglądarce.
7. Storage bez własnych reguł
Cloud Storage ma własne reguły i często się o nich zapomina. Z allow read, write: if request.auth != null każdy zarejestrowany użytkownik może czytać pliki innych, wgrywać cokolwiek pod dowolną ścieżkę i zapełnić Twój limit. Rozsądna reguła ogranicza ścieżkę do użytkownika i waliduje rozmiar oraz typ:
match /users/{userId}/{fileName} {
allow read: if request.auth != null && request.auth.uid == userId;
allow write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*');
}8. Otwarta Realtime Database
Jeśli zamiast Firestore używasz bazy czasu rzeczywistego, odpowiednikiem jest ".read": true w korzeniu. Reguły to inny język, ale logika ta sama: nic otwartego w korzeniu i uprawnienia per gałąź z auth.uid.
9. Zapis bez walidacji
Pozwolenie na zapis właścicielowi dokumentu nie wystarczy, jeśli nie walidujesz, co zapisuje. Użytkownik może dodać isAdmin: true albo plan: "pro" do własnego profilu z konsoli przeglądarki. Waliduj pola przez request.resource.data: jakie klucze istnieją, jakiego są typu i czy wrażliwe pola się nie zmieniają.
allow update: if request.auth.uid == userId
&& !request.resource.data.diff(resource.data).affectedKeys()
.hasAny(['isAdmin', 'plan', 'credits']);10. Zapominanie o rachunku
Firebase liczy za odczyt. Reguła, która pozwala na list bez limitu w dużej kolekcji, pozwala skryptowi przeczytać miliony dokumentów i wygenerować Ci nieoczekiwany rachunek. Ogranicz zapytania w regułach (request.query.limit <= 100), włącz App Check i ustaw alerty budżetowe w Google Cloud.
Jak sprawdzić to samodzielnie
- Symulator reguł. W konsoli Firebase, zakładka Reguły, jest symulator, w którym testujesz odczyt jako użytkownik anonimowy albo z konkretnym UID. Spróbuj odczytać
usersbez sesji: musi zostać odrzucone. - Emulator z testami. Lokalny emulator pozwala pisać automatyczne testy reguł. To jedyny sposób, żeby nie zepsuć ich przy zmianach.
- Z zewnątrz, bez tokena. REST API Firestore odpowiada każdemu:
curl "https://firestore.googleapis.com/v1/projects/TWOJ_PROJEKT/databases/(default)/documents/users"Jeśli zwraca dokumenty, ta kolekcja jest otwarta. Jeśli zwraca błąd uprawnień, reguła działa. Powtórz dla każdej kolekcji, którą masz.
Scanaris sprawdza Twój Firebase z zewnątrz
Scanaris wykrywa konfigurację Firebase w Twoim bundle'u, sprawdza, czy typowe kolekcje odpowiadają bez uwierzytelnienia, szuka innych kluczy, których nie powinno być w przeglądarce, i sprawdza nagłówki, CORS oraz wystawione pliki. Dla każdego znaleziska dostajesz fix prompt z dokładną regułą lub zmianą do wklejenia w Lovable, Bolt lub Cursor. To kontrole tylko do odczytu na tym, co już jest publiczne. Pełna lista ryzyk jest w przewodniku bezpieczeństwa dla Firebase, a przed startem warto przejrzeć checklistę bezpieczeństwa.
Często zadawane pytania
Czy to problem, że mój apiKey Firebase jest w kodzie?
Sam w sobie nie: identyfikuje projekt, nie daje uprawnień. To, co chroni dane, to reguły. Mimo to ogranicz klucz do swoich domen i włącz App Check, żeby zapobiec nadużyciom.
Co zrobić, jeśli moje reguły są teraz otwarte?
Najpierw zamknij: ustaw reguły per kolekcja z request.auth.uid, nawet jeśli jakaś funkcja przestanie działać, a aplikację napraw potem. Następnie sprawdź w logach użycia, czy były nietypowe odczyty, a jeśli wystawione były dane osobowe, rozważ, czy musisz to zgłosić.
Czy mogę poprosić swoją AI o napisanie reguł?
Tak, i zwykle robi to dobrze, jeśli podasz jej strukturę kolekcji i kto ma co widzieć. Ale przetestuj je w symulatorze przed publikacją: AI też pisze if request.auth != null w przekonaniu, że to bezpieczne.