Z tego przewodnika dowiesz się, jakie są typowe luki w zabezpieczeniach w konfiguracjach Firebase Security Rules, jak sprawdzić i poprawić zabezpieczenia własnych reguł oraz jak przetestować zmiany przed ich wdrożeniem.
Jeśli otrzymasz alert, że Twoje dane nie są odpowiednio zabezpieczone, sprawdzić te typowe błędy i zaktualizować reguły z lukami w zabezpieczeniach.
Dostęp do Firebase Security Rules
Aby wyświetlić obecne Rules, użyj interfejsu wiersza poleceń Firebase lub Firebase. Pamiętaj, aby w ten sam sposób edytować reguły, konsekwentnie, aby uniknąć przypadkowego zastępowania aktualizacji. Jeśli nie masz pewności, czy zdefiniowane lokalnie reguły odzwierciedlają najnowsze zmiany, konsola Firebase zawsze pokazuje najnowszą wersję Firebase Security Rules.
Aby uzyskać dostęp do reguł w konsoli Firebase, wybierz projektu, a następnie przejdź do Realtime Database, Cloud Firestore lub Miejsce na dane. Gdy znajdziesz się w odpowiedniej bazie danych lub miejscu, kliknij Reguły. zasobnika.
Aby uzyskać dostęp do reguł z poziomu interfejsu wiersza poleceń Firebase, otwórz reguł zanotowanych w pliku firebase.json.
Poznaj Firebase Security Rules
Firebase Security Rules chroni Twoje dane przed szkodliwymi użytkownikami. Podczas tworzenia bazy danych lub zasobnik Cloud Storage w konsoli Firebase, możesz odmówić dostępu wszystkim użytkownikom (tryb blokady) lub przyznać dostęp wszystkich użytkowników (tryb testowy). Chociaż możesz potrzebować bardziej otwartej konfiguracji programisty, zadbaj o to, by prawidłowo skonfigurować reguły i zabezpiecza dane przed wdrożeniem aplikacji.
W miarę rozwijania aplikacji i testowania różnych jej konfiguracji reguły, użyj jednego z lokalnych emulatorów Firebase, aby uruchomić aplikację. w lokalnym środowisku programistycznym.
Typowe scenariusze korzystania z niezabezpieczonych reguł
Rules, które możesz skonfigurować domyślnie lub we własnym zakresie pracy nad Twoją aplikacją należy przejrzeć i zaktualizować przed wdrożeniem aplikacji. Zadbaj o prawidłowe zabezpieczenie użytkowników dane dzięki unikaniu tych typowych pułapek.
Otwarty dostęp
Podczas konfigurowania projektu Firebase mogłeś/mogłaś ustawić reguły, które zezwalają na otwarty dostęp podczas tworzenia. Możesz pomyśleć, że jesteś jedyną osobą, która korzysta z ale jeśli została wdrożona, jest dostępna w internecie. Jeśli nie uwierzytelniasz użytkowników ani nie konfigurujesz reguł zabezpieczeń, każda osoba, która zgadnie identyfikator Twojego projektu, może wykraść, zmodyfikować lub usunąć dane.
Niezalecane: uprawnienia do odczytu i zapisu w przypadku:
wszystkich użytkowników.
Cloud Firestore// Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if true; } } } Realtime Database{ // Allow read/write access to all users under any conditions // Warning: **NEVER** use this ruleset in production; it allows // anyone to overwrite your entire database. "rules": { ".read": true, ".write": true } } Cloud Storage// Anyone can read or write to the bucket, even non-users of your app. // Because it is shared with App Engine, this will also make // files uploaded via App Engine public. // Warning: This rule makes every file in your Cloud Storage bucket accessible to any user. // Apply caution before using it in production, since it means anyone // can overwrite all your files. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write; } } } |
Rozwiązanie: reguły, które ograniczają odczyt
uprawnień do zapisu.
Twórz reguły, które mają sens w przypadku Twojej hierarchii danych. Jednym z typowych rozwiązań z tym brakiem bezpieczeństwa są oparte na użytkownikach w Firebase Authentication. Więcej informacji o uwierzytelniania użytkowników za pomocą reguł. Cloud FirestoreRealtime DatabaseCloud Storage |
Dostęp dla dowolnego uwierzytelnionego użytkownika
Czasami Rules sprawdza, czy użytkownik jest zalogowany, ale nie wykonuje dalszych czynności
ogranicza dostęp na podstawie tego uwierzytelniania. Jeśli jedna z reguł zawiera parametr auth != null
, potwierdź, że chcesz, aby każdy zalogowany użytkownik miał dostęp do danych.
Niezalecane: każdy zalogowany użytkownik ma dostęp do odczytu i edycji całej bazy danych.
Cloud Firestoreservice cloud.firestore { match /databases/{database}/documents { match /some_collection/{document} { allow read, write: if request.auth.uid != null; } } } Realtime Database{ "rules": { ".read": "auth.uid !== null", ".write": "auth.uid !== null" } } Cloud Storage// Only authenticated users can read or write to the bucket service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if request.auth != null; } } } |
Rozwiązanie: ograniczenie dostępu za pomocą zabezpieczeń
warunków.
Przy sprawdzaniu uwierzytelniania możesz też używać go właściwości uwierzytelniania, aby jeszcze bardziej ograniczyć dostęp do konkretnych użytkowników dla konkretnych zbiorów danych. Dowiedz się więcej o różnych właściwości uwierzytelniania. Cloud FirestoreRealtime DatabaseCloud Storage |
(Realtime Database) Nieprawidłowo dziedziczone reguły
Realtime Database Security Rules kaskadowo, przy czym reguły na krótszych ścieżkach nadrzędnych zastępują reguły na dłuższych ścieżkach podrzędnych. Pisząc regułę w węźle podrzędnym, pamiętaj, że może tylko przyznawać uprawnienia. Nie można zawęzić ani unieważnić na głębszą ścieżkę w bazie danych.
Niezalecane: doprecyzowywanie reguł w ścieżkach podrzędnych
{ "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { /* ignored, since read was allowed already */ ".read": false } } } } |
Rozwiązanie: na ścieżkach nadrzędnych zapisz reguły o szerokim zakresie, a na ścieżkach podrzędnych nadaj bardziej szczegółowe uprawnienia. Jeśli Twoje potrzeby dotyczące dostępu do danych wymagają większej szczegółowości, zachowaj szczegółowość reguł. Więcej informacji o kaskadzie Realtime Database Security Rules w Rdzeń składni słowa Realtime Database Security Rules. |
Zamknięty dostęp
Podczas tworzenia aplikacji możesz też zablokować dane. Zwykle oznacza to, że odczyt i zapis są wyłączone dostęp dla wszystkich użytkowników w następujący sposób:
Cloud Firestore
// Deny read/write access to all users under any conditions service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if false; } } }
Realtime Database
{ "rules": { ".read": false, ".write": false } }
Cloud Storage
// Access to files through Cloud Storage is completely disallowed. // Files may still be accessible through App Engine or Google Cloud Storage APIs. service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if false; } } }
Pakiety Firebase Admin SDK i Cloud Functions nadal mają dostęp do w bazie danych. Użyj tych reguł, gdy chcesz używać zmiennych Cloud Firestore lub Realtime Database tylko dla serwera w połączeniu z Firebase Admin SDK. Mimo że jest to bezpieczne, sprawdź, czy klienci aplikacji mogą prawidłowo pobierać dane.
Dowiedz się więcej o funkcji Cloud Firestore Security Rules i o tym, jak działa Pierwsze kroki z usługą Cloud Firestore Security Rules.
Przetestuj urządzenie Cloud Firestore Security Rules
Aby sprawdzić działanie aplikacji i sprawdzić konfiguracje Cloud Firestore Security Rules, użyj emulatora Firebase. Przed wdrożeniem zmian uruchom i zautomatyzuj testy jednostkowe w środowisku lokalnym za pomocą emulatora Cloud Firestore.
Aby szybko zweryfikować Firebase Security Rules w konsoli Firebase, użyj symulatora reguł Firebase.