Generator reguł bezpieczeństwa Firebase

Generuj reguły bezpieczeństwa dla Firebase Firestore i Storage. Kontrola dostępu, autoryzacja użytkowników. Pobierz gotowy kod.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Ustawienia

Preset

Owner mode

Path

Allow read Opcja narzędzia

Allow write Opcja narzędzia

Require auth Opcja narzędzia

Owner field

Claim kluczy

Claim value

Expires dni

Wynik

Baza danych

Cloud Firestore

Wzorzec reguł

Tylko właściciel

Ścieżka

users/{userId}

Odczyt

Dozwolony

Zapis

Dozwolony

rules_version = '2';
service cloud.firestore {
  // Wygenerowano w generatorze reguł Firebase (webp.pl). Przetestuj reguły w emulatorze przed wdrożeniem.
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null && request.auth.uid == userId;
      allow write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Ściąga: warunki dostępu każdego wzorca — wygenerowane silnikiem tego narzędzia (Firestore, ścieżka users/{userId}, wymóg logowania)

Wzorzec	allow read	allow write	Na co uważać
Publiczny odczyt	`true;`	`request.auth != null;`	KAŻDY (także niezalogowany) czyta; zapis wymaga zalogowania — silnik wymusza to osobno
Zalogowani użytkownicy	`request.auth != null;`	`request.auth != null;`	każdy zalogowany widzi i zmienia WSZYSTKIE dokumenty w ścieżce — brak izolacji między użytkownikami
Tylko właściciel	`request.auth != null && request.auth.uid == userId;`	`request.auth != null && request.auth.uid == userId;`	dostęp tylko, gdy uid zalogowanego zgadza się ze zmienną w ścieżce ({userId}); tryb „field” porównuje pole dokumentu
Role (custom claims)	`request.auth != null && request.auth.token.role == 'admin';`	`request.auth != null && request.auth.token.role == 'admin';`	wymaga custom claim ustawionego Admin SDK (auth.token.role == admin) — sam zapis reguły niczego nikomu nie nadaje
Ograniczony czasowo	`request.auth != null && request.time < timestamp.date(2026, 11, 19);`	`request.auth != null && request.time < timestamp.date(2026, 11, 19);`	dostęp wygasa po dacie z reguły (request.time < timestamp.date) — zegar serwera Firebase, nie Twojego urządzenia
Własny (tylko przełącznik auth)	`request.auth != null;`	`request.auth != null;`	warunek to wyłącznie przełącznik „wymagaj logowania”; bez zaznaczenia dopuszcza WSZYSTKICH

Realtime Database: ta sama logika, ale składnia inna — warunki używają auth != null (bez request.), daty to now < ms-od-epoki, a reguły zapisywane są jako JSON z kluczami .read/.write w drzewie ścieżek. Reguły zakomentowane (// allow …) oznaczają brak dostępu — Firebase domyślnie zabrania wszystkiego, czego reguła nie dopuszcza.

Fałszywe poczucie bezpieczeństwa: wygenerowany plik to dopiero projekt reguł. Dopóki nie przetestujesz go w emulatorze Firebase albo w symulatorze reguł w konsoli, nie wiesz, co realnie przepuszcza — a wdrożenie zbyt luźnych reguł (zwłaszcza if true) otwiera bazę wszystkim. Po wdrożeniu sprawdź też, czy stara reguła nie została gdzieś wyżej w drzewie ścieżek: w Firestore i RTDB bardziej szczegółowa reguła nie „nadpisuje” dostępu z reguły nadrzędnej — dostęp przyznany wyżej dziedziczy się w dół.

Reguły Firebase: ostatnia linia obrony danych

Reguły to nie firewall aplikacji

Reguły działają bezpośrednio w Firebase — klient ma dostęp do tego, co reguła dopuści, nawet jeśli Twój frontend tego nie wyświetla. Walidacja pól, limitów i ról należy do reguł, bo jedynie one egzekwują ją dla każdego klienta, także zmodyfikowanego.

Publiczny odczyt — świadomie

Wzorzec „publiczny odczyt” generuje if true: każdy niezalogowany czyta całą ścieżkę. Nadaje się na dane publiczne (katalog, treści CMS), nigdy na profile i ustawienia użytkowników. Zapis silnik i tak zabezpiecza wymogiem logowania — publiczny zapis nigdy nie jest generowany.

Testuj przed wdrożeniem

Emulator Suite uruchamia Firestore i RTDB lokalnie z Twoimi regułami, a symulator reguł w konsoli Firebase pozwala sprawdzić konkretną operację (get/list/create/update/delete) dla zalogowanego i anonimowego użytkownika. Wdrożenie bez testu to najczęstsza droga do przypadkowo otwartej bazy.

Role i daty wymagają przygotowania

Wzorzec rolowy czyta auth.token.role — claim musi najpierw ustawić serwer przez Admin SDK (setCustomUserClaims), sama reguła nikogo administratorem nie zrobi. Podobnie czasowy limit działa na zegarze Firebase i wygasa twardo: po dacie dostęp znika wszystkim, także Tobie.

Wskazówka: kafelki nad wynikiem pokazują bazę, wzorzec, ścieżkę i stan odczytu/zapisu — a eksport zapisuje reguły z rozszerzeniem dopasowanym do produktu (.rules dla Firestore, .json dla Realtime Database).

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator reguł bezpieczeństwa Firebase — Firestore i Storage Rules

Generator reguł bezpieczeństwa Firebase tworzy szablony reguł bezpieczeństwa dla Firebase Firestore i Storage — dostosowane do typowych wzorców dostępu: wyłącznie autoryzowani użytkownicy, dostęp właściciela, reguły oparte na rolach (RBAC) i wiele innych.

Czym są reguły bezpieczeństwa Firebase?

Firebase Security Rules to język deklaratywny definiujący, kto i w jakich warunkach może czytać lub zapisywać dane w Firestore, Realtime Database i Storage. Reguły działają po stronie serwera — klient nie może ich obejść, nawet modyfikując kod JavaScript. Są kluczowym elementem bezpieczeństwa każdej aplikacji Firebase.

Domyślna konfiguracja Firebase po stworzeniu projektu zezwala na odczyt i zapis każdemu (publicznie) lub blokuje wszystkich — żadna z opcji nie jest dobra dla produkcji. Zawsze zdefiniuj granularne reguły przed wdrożeniem.

Podstawowe wzorce reguł Firestore

Tylko uwierzytelnieni: allow read, write: if request.auth != null; — tylko zalogowani użytkownicy. Tylko właściciel: allow read, write: if request.auth.uid == resource.data.userId; — tylko twórca dokumentu. Odczyt publiczny, zapis uwierzytelniony: allow read: if true; allow write: if request.auth != null; — idealny dla blogów. RBAC — role-based access: sprawdzenie roli użytkownika w osobnym dokumencie /users/{uid}. Walidacja danych: request.resource.data.title is string — sprawdzenie typów przed zapisem.

Reguły Firebase Storage

Reguły Storage są podobne do Firestore, ale operują na ścieżkach plików. Typowe wzorce: zezwolenie na upload zdjęcia tylko zalogowanym użytkownikom, limitowanie rozmiaru pliku (request.resource.size < 5 * 1024 * 1024 dla max 5MB), ograniczenie typu pliku (request.resource.contentType.matches('image/.*')), dostęp tylko do własnych plików (userId == request.auth.uid).

Testowanie i debugowanie reguł

Firebase Emulator Suite pozwala testować reguły lokalnie bez dotykania produkcji: firebase emulators:start. Firebase Console zawiera Rules Playground — możesz symulować żądania i sprawdzić, czy są akceptowane lub odrzucane. Zawsze testuj reguły przed wdrożeniem do produkcji — błąd może zablokować dostęp do danych lub otworzyć lukę bezpieczeństwa.

Najczęściej zadawane pytania

Jak zezwolić na odczyt dokumentu tylko jego właścicielowi?

W Firestore: match /users/{userId} { allow read, write: if request.auth.uid == userId; }. Dla zagnieżdżonych kolekcji: match /posts/{postId} { allow read, write: if request.auth.uid == resource.data.authorId; }. Zakładamy, że każdy dokument postu ma pole authorId ustawione na UID twórcy.

Jak zaimplementować role (admin, user) w Firebase Security Rules?

Przechowuj role w kolekcji /users/{uid}: {role: "admin"}. W regułach: function isAdmin() { return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "admin"; }. Następnie: allow write: if isAdmin();. Pamiętaj: funkcja get() kosztuje odczyt — unikaj wywołań w hot paths.

Jak walidować dane przed zapisem w Firestore?

Użyj request.resource.data dla walidacji nowych danych: allow write: if request.resource.data.title is string && request.resource.data.title.size() <= 100 && request.resource.data.createdAt == request.time;. To gwarantuje, że klient nie może zapisać nieprawidłowych danych, nawet przy bezpośrednim dostępie do SDK.

Czy Firebase Security Rules zastępują walidację po stronie serwera?

Nie — Firebase Security Rules są uzupełnieniem, nie zastępstwem, walidacji po stronie serwera. Reguły chronią przed nieautoryzowanym dostępem bezpośrednio do Firestore. Ale dla złożonych operacji biznesowych (transakcje, operacje na wielu dokumentach, integracje zewnętrzne) używaj Firebase Cloud Functions z własną logiką walidacji.

Co to jest request.auth.token i jak go używać w regułach?

request.auth.token zawiera zdekodowany JWT token Firebase Authentication — zawiera standardowe claims (uid, email, email_verified) i niestandardowe claims ustawione przez Firebase Admin SDK. Przykład: allow write: if request.auth.token.admin == true;. Niestandardowe claims ustawiasz przez Admin SDK: admin.auth().setCustomUserClaims(uid, {admin: true}).

Czy reguły bezpieczeństwa Firebase można obejść z poziomu klienta?

Nie. Ocena reguł odbywa się na serwerach Firebase, a nie w przeglądarce, więc modyfikacja kodu JavaScript nic nie zmieni. Klient może jedynie wysłać żądanie, które zostanie przyjęte albo odrzucone.

Czym różni się resource.data od request.resource.data w regułach Firestore?

resource.data to dokument już zapisany w bazie, a request.resource.data to dane przychodzące w bieżącym żądaniu. Przy tworzeniu dokumentu resource.data nie istnieje, dlatego reguły dla operacji create muszą opierać się na request.resource.data.

Jak ograniczyć upload w Firebase Storage do obrazów o rozmiarze do 5 MB?

W jednej regule zapisu połącz dwa warunki: request.resource.size < 5 * 1024 * 1024 oraz request.resource.contentType.matches('image/.*'). Pierwszy pilnuje rozmiaru, drugi typu pliku.

Czy w regułach Storage można sprawdzać dane z Firestore?

Tak, reguły Storage mają dostęp do API Firestore przez firestore.get() i firestore.exists(). Każde takie odwołanie zwiększa jednak koszt oceny reguły, więc warto używać ich oszczędnie lub przenieść role do custom claims w tokenie.

Co się stanie, jeśli nie wdrożę wygenerowanych reguł?

W projekcie pozostanie konfiguracja domyślna, która albo blokuje wszystkich, albo pozwala na swobodny dostęp. Plik reguł w repozytorium nie działa, dopóki nie zostanie wdrożony poleceniem firebase deploy.

Jak wybór wzorca dostępu zamienia się w plik reguł

Generator nie analizuje Twojego kodu ani struktury bazy. Działa jak szablonownik: z listy wybierasz produkt (Firestore albo Cloud Storage), wzorzec dostępu (tylko zalogowani, właściciel zasobu, RBAC, odczyt publiczny z zapisem dla zalogowanych) i podajesz kilka nazw — ścieżkę kolekcji lub katalogu, nazwę pola z identyfikatorem właściciela oraz ścieżkę dokumentu z rolą. Na tej podstawie powstaje gotowy plik z blokiem rules_version = '2', deklaracją usługi i zagnieżdżonymi blokami match, w których znajdują się warunki allow.

Kluczowe jest rozróżnienie trzech źródeł danych w warunku. request.auth opisuje nadawcę żądania i jego token, resource to dokument lub plik już zapisany w bazie, a request.resource to dane przychodzące w tym żądaniu. Dlatego reguła właściciela dla aktualizacji odwołuje się do resource.data (stan przed zmianą), a dla tworzenia musi użyć request.resource.data — przy tworzeniu dokument jeszcze nie istnieje, więc odwołanie do resource.data kończy się odrzuceniem żądania.

Warunki w obrębie jednego bloku match sumują się logicznie: jeśli którakolwiek reguła allow zezwala na daną operację, dostęp jest przyznany. Powtarzalne fragmenty (sprawdzenie właściciela, sprawdzenie roli) generator wyprowadza do funkcji, które można wywołać w wielu blokach. Tak przygotowany tekst wkleja się do pliku firestore.rules lub storage.rules i wdraża poleceniem firebase deploy --only firestore:rules albo storage:rules — sam plik w repozytorium nic nie zmienia, dopóki nie trafi na serwer.

Przykład krok po kroku: blog z publicznym odczytem i rolą administratora

Załóż, że masz kolekcję posts, każdy dokument zawiera pole authorId z uid autora, a role trzymasz w kolekcji users w polu role. Chcesz, aby wpisy czytał każdy, tworzył i edytował tylko autor, a usuwać mógł autor lub administrator.
W generatorze wybierz produkt Firestore, wzorzec właściciela rozszerzony o rolę, wpisz ścieżkę kolekcji posts, pole właściciela authorId oraz ścieżkę ról users/{uid} z polem role.
Otrzymasz blok match /posts/{postId} z regułą odczytu dla wszystkich oraz osobnymi regułami dla create, update i delete. Tworzenie sprawdza zgodność nadawcy z polem autora w danych przychodzących: request.auth.uid == request.resource.data.authorId.
Aktualizacja i usunięcie korzystają z funkcji właściciela, która porównuje uid z wartością zapisaną w dokumencie, oraz z funkcji roli, która pobiera dokument użytkownika przez get() i sprawdza jego pole role.
Do reguł zapisu dochodzi walidacja typów, np. request.resource.data.title is string i request.resource.data.authorId == resource.data.authorId, aby autor nie przepisał dokumentu na cudze konto.
Skopiuj wynik do pliku reguł w projekcie, wdróż go i sprawdź w Rules Playground oraz w emulatorze: żądanie bez tokenu, żądanie autora i żądanie administratora powinny dać trzy różne odpowiedzi.

Wzorce dostępu i ich odpowiedniki w regułach

Wzorzec dostępu	Firestore	Cloud Storage
Tylko zalogowani	allow read, write: if request.auth != null;	allow read, write: if request.auth != null;
Właściciel zasobu	allow write: if request.auth.uid == resource.data.userId;	allow write: if request.auth.uid == userId ze ścieżki pliku;
Odczyt publiczny, zapis dla zalogowanych	allow read: if true; allow write: if request.auth != null;	allow read: if true; allow write: if request.auth != null;
RBAC z dokumentu użytkownika	get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin'	firestore.get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin'
Walidacja typu pola	request.resource.data.title is string	request.resource.contentType.matches('image/.*')
Limit rozmiaru pliku	nie dotyczy — reguła dotyczy dokumentu, nie pliku	request.resource.size < 5 * 1024 * 1024
Całkowita blokada	allow read, write: if false;	allow read, write: if false;
Uprawnienia z tokenu	request.auth.token.role == 'admin'	request.auth.token.role == 'admin'

Praktyczne wskazówki przy pracy z wygenerowanymi regułami

Trzymaj powtarzalne warunki w funkcjach. Sprawdzenie właściciela i roli używaj w wielu blokach match przez jedną funkcję — łatwiej wtedy poprawić logikę w jednym miejscu i trudniej o rozjazd między kolekcjami.
Rozdzielaj create od update. Przy tworzeniu nie ma stanu poprzedniego, więc warunek musi opierać się na request.resource.data. Przy aktualizacji porównuj dane przychodzące z zapisanymi, jeśli jakaś wartość nie może się zmieniać.
Dodawaj walidację w tej samej regule co kontrolę dostępu. Sama weryfikacja zalogowania nie chroni przed zapisaniem dokumentu o złej strukturze ani pliku w nieoczekiwanym formacie.
Ograniczaj odwołania do innych dokumentów. Każde get() i exists() w warunku to dodatkowa praca przy ocenie reguły i dodatkowy odczyt. Role lepiej trzymać w tokenie jako custom claims, jeśli nie muszą zmieniać się natychmiast.
Testuj przed wdrożeniem i po nim. Przygotuj trzy scenariusze: brak tokenu, zwykły użytkownik, administrator. Rules Playground i emulator pozwalają sprawdzić decyzję bez dotykania środowiska produkcyjnego.

Czego generator nie uwzględnia

Nie zna Twojego modelu danych. Zakłada, że pole właściciela leży bezpośrednio w dokumencie i ma nazwę, którą podałeś. Przy zagnieżdżonych polach, tablicach albo wartości wyliczanej po stronie serwera warunek trzeba napisać ręcznie.
Nie sprawdza zgodności z zapytaniami klienta. W Firestore reguła nie filtruje wyników — jeśli wymaga dopasowania po polu właściciela, zapytanie bez takiego filtra zostanie odrzucone w całości, choć pojedyncze dokumenty byłyby dostępne.
Nie zastępuje pozostałych zabezpieczeń projektu. Reguły chronią dane w bazie i plikach, ale nie ograniczają nadużyć API, nie zastępują App Check, limitów i poprawnej konfiguracji kluczy.
Nie wykryje błędów składni za Ciebie. Wygenerowany tekst to propozycja do wklejenia — literówka w nazwie pola lub brakujący przecinek ujawni się dopiero przy wdrożeniu lub w emulatorze, jako odrzucone żądanie.