Aby chronić zasoby Firebase i dane użytkowników, postępuj zgodnie z tymi wskazówkami. Nie wszystkie elementy będą miały zastosowanie w Twoim przypadku, ale pamiętaj o nich podczas tworzenia aplikacji.
Unikanie szkodliwego ruchu
Konfigurowanie monitorowania i alertów dla usług backendu
Aby wykrywać szkodliwy ruch, np. ataki typu DoS, skonfiguruj monitorowanie i alerty dla Cloud Firestore, Realtime Database, Cloud Storage i Hosting
Jeśli podejrzewasz atak na swoją aplikację, jak najszybciej skontaktuj się z zespołem pomocy, aby poinformować go o sytuacji.
Włącz App Check
Aby mieć pewność, że tylko Twoje aplikacje mają dostęp do usług backendu, włącz Firebase App Check w każdej usłudze, która je obsługuje.
Konfigurowanie Cloud Functions do skalowania w przypadku normalnego ruchu
Cloud Functions automatycznie skaluje się, aby sprostać wymaganiom aplikacji, ale w przypadku ataku może to oznaczać wysoki rachunek. Aby temu zapobiec, możesz ograniczyć liczbę równoczesnych instancji funkcji na podstawie normalnego ruchu w aplikacji.
Konfigurowanie alertów, aby otrzymywać powiadomienia, gdy limity są bliskie wyczerpania
Jeśli w usłudze występują nagłe wzrosty liczby żądań, często włączają się limity i automatycznie ograniczają ruch w aplikacji.
Pamiętaj, aby monitorować panel Użycie i rozliczenia dashboard.
Skonfiguruj alerty dotyczące budżetu w projekcie, aby otrzymywać powiadomienia, gdy wykorzystanie zasobów przekroczy oczekiwania.
Jeśli używasz Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase i Firebase Extensions, ustaw limity wydatków, aby wstrzymać odpowiednią usługę, gdy projekt osiągnie budżet ustawiony dla tej usługi.
Zapobieganie atakom typu DoS na własną aplikację: testowanie funkcji lokalnie za pomocą emulatorów
Podczas tworzenia Cloud Functions łatwo można przypadkowo spowodować atak typu DoS na własną aplikację, np. tworząc nieskończoną pętlę wyzwalacza. Aby zapobiec takim błędom, możesz tworzyć aplikacje za pomocą pakietu Firebase Local Emulator Suite.
Jeśli przypadkowo spowodujesz atak typu DoS na własną aplikację, wycofaj wdrożenie funkcji, usuwając ją
z index.js a następnie uruchamiając
firebase deploy --only functions
Jeśli responsywność w czasie rzeczywistym jest mniej ważna, skonfiguruj funkcje w sposób defensywny
Jeśli nie musisz prezentować wyniku funkcji w czasie rzeczywistym, możesz ograniczyć szkodliwy ruch, przetwarzając wyniki w partiach: publikuj wyniki w Pub/Sub temacie i przetwarzaj je w regularnych odstępach czasu za pomocą zaplanowanej funkcji.
Informacje o kluczach interfejsu API
Klucze interfejsu API usług Firebase nie są tajne
Klucze interfejsu API usług Firebase tylko identyfikują Twój projekt w Firebase i aplikację w tych usługach. Autoryzacja jest obsługiwana za pomocą Google Cloud uprawnień IAM, Firebase Security Rules, i Firebase App Check.
Wszystkie klucze interfejsu API udostępniane przez Firebase są automatycznie ograniczone do interfejsów API związanych z Firebase. Jeśli konfiguracja aplikacji jest zgodna z wytycznymi na tej stronie, klucze interfejsu API ograniczone do usług Firebase nie muszą być traktowane jako tajne i można je bezpiecznie umieszczać w kodzie lub plikach konfiguracyjnych.
Konfigurowanie ograniczeń klucza interfejsu API
Jeśli używasz kluczy interfejsu API w innych usługach Google, pamiętaj, aby zastosować ograniczenia klucza interfejsu API aby ograniczyć zakres kluczy interfejsu API do klientów aplikacji i używanych interfejsów API.
Używaj kluczy interfejsu API udostępnianych przez Firebase tylko w przypadku interfejsów API związanych z Firebase. Jeśli Twoja aplikacja korzysta z innych interfejsów API (np. Places API for Maps lub the Gemini Developer API), użyj a separate API key and restrict it to the applicable API.
Zachowaj tajność kluczy serwera FCM
W przeciwieństwie do kluczy interfejsu API usług Firebase klucze serwera FCM (używane przez starszy interfejs FCM HTTP API) są poufne i muszą być utrzymywane w tajemnicy.
Zachowaj tajność kluczy konta usługi
W przeciwieństwie do kluczy interfejsu API usług Firebase klucze prywatne konta usługi (używane przez the Firebase Admin SDK) są poufne i muszą być utrzymywane w tajemnicy.
Firebase Security Rules
Inicjowanie reguł w trybie produkcyjnym lub blokady
Podczas konfigurowania Cloud Firestore, Realtime Database i Cloud Storage zainicjuj Firebase Security Rules, aby domyślnie odmawiać dostępu, i dodaj reguły, które przyznają dostęp do określonych zasobów podczas tworzenia aplikacji.
Użyj jednego z ustawień domyślnych dla nowych instancji Cloud Firestore (tryb produkcyjny) i Realtime Database (tryb blokady). W przypadku Cloud Storage zacznij od konfiguracji reguł bezpieczeństwa, takiej jak ta:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Reguły bezpieczeństwa to schemat. Dodawaj reguły podczas dodawania dokumentów
Nie pisz reguł bezpieczeństwa po napisaniu aplikacji, jako zadania przed uruchomieniem. Zamiast tego pisz reguły bezpieczeństwa podczas tworzenia aplikacji, traktując je jak schemat bazy danych: gdy musisz użyć nowego typu dokumentu lub struktury ścieżki, najpierw napisz regułę bezpieczeństwa.
Testowanie jednostkowe reguł bezpieczeństwa za pomocą Local Emulator Suite; dodawanie go do CI
Aby mieć pewność, że reguły bezpieczeństwa są zgodne z rozwojem aplikacji, testuj je jednostkowo za pomocą Firebase Local Emulator Suite i dodaj te testy do potoku CI. Zapoznaj się z tymi przewodnikami dotyczącymi Cloud Firestore i Realtime Database.
Uwierzytelnianie
Uwierzytelnianie niestandardowe: generowanie tokenów JWT w zaufanym środowisku (po stronie serwera)
Jeśli masz już bezpieczny system logowania, np. system niestandardowy lub usługę innej firmy, możesz użyć go do uwierzytelniania w usługach Firebase. Utwórz niestandardowe tokeny JWT w zaufanym środowisku, a następnie przekaż je do klienta, który używa tokena do uwierzytelniania (iOS+, Android, Web, Unity, C++).
Przykład użycia uwierzytelniania niestandardowego z dostawcą zewnętrznym znajdziesz w poście na blogu Uwierzytelnianie w Firebase za pomocą Okta.
Uwierzytelnianie zarządzane: dostawcy OAuth 2.0 są najbezpieczniejsi
Jeśli używasz funkcji uwierzytelniania zarządzanego przez Firebase, najbezpieczniejsze są opcje dostawcy OAuth 2.0 / OpenID Connect (Google, Facebook itp.). Jeśli to możliwe, obsługuj co najmniej jednego z tych dostawców (w zależności od bazy użytkowników).
Uwierzytelnianie za pomocą adresu e-mail i hasła: ustawienie ścisłego limitu dla punktu końcowego logowania, aby zapobiec atakom brute force
Jeśli używasz usługi uwierzytelniania za pomocą adresu e-mail i hasła zarządzanej przez Firebase, zaostrz domyślny limit punktów końcowych identitytoolkit.googleapis.com, aby zapobiec atakom brute force. Możesz to zrobić na stronie
Identity Toolkit API
w konsoli Google Cloud.
Uwierzytelnianie za pomocą adresu e-mail i hasła: włączanie ochrony przed wyliczaniem adresów e-mail
Jeśli używasz usługi uwierzytelniania za pomocą adresu e-mail i hasła zarządzanej przez Firebase, włącz ochronę przed wyliczaniem adresów e-mail, która uniemożliwia złośliwym podmiotom nadużywanie punktów końcowych uwierzytelniania projektu do odgadywania nazw kont.
Uaktualnianie do Google Cloud Identity Platform w celu uwierzytelniania wielopoziomowego
Aby zwiększyć bezpieczeństwo logowania, możesz dodać obsługę uwierzytelniania wielopoziomowego uaktualniając do Google Cloud Identity Platform. Po uaktualnieniu dotychczasowy kod Firebase Authentication będzie nadal działać.
Uwierzytelnianie anonimowe
Używaj uwierzytelniania anonimowego tylko w przypadku wstępnego onboardingu
Używaj uwierzytelniania anonimowego tylko do zapisywania podstawowego stanu użytkowników przed ich zalogowaniem. Uwierzytelnianie anonimowe nie zastępuje logowania użytkownika.
Przekształcanie użytkowników na inną metodę logowania, jeśli chcą mieć dostęp do swoich danych na innych urządzeniach
Dane uwierzytelniania anonimowego nie będą się utrzymywać, jeśli użytkownik wyczyści pamięć lokalną lub zmieni urządzenie. Jeśli musisz zachować dane po ponownym uruchomieniu aplikacji na jednym urządzeniu, przekształć użytkownika na stałe konto.
Używanie reguł bezpieczeństwa, które wymagają od użytkowników przekształcenia na dostawcę logowania lub zweryfikowania adresu e-mail
Każdy może utworzyć anonimowe konto w Twoim projekcie. Pamiętaj o tym i chroń wszystkie dane niepubliczne za pomocą reguł bezpieczeństwa, które wymagają określonych metod logowania lub zweryfikowanych adresów e-mail.
Przykład:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Bezpieczeństwo Cloud Functions
Nigdy nie umieszczaj informacji poufnych w zmiennych środowiskowych
W aplikacji Node.js hostowanej samodzielnie często używasz zmiennych środowiskowych do przechowywania informacji poufnych, takich jak klucze prywatne. Nie rób tego w Cloud Functions. Ponieważ Cloud Functions ponownie wykorzystuje środowiska między wywołaniami funkcji, informacje poufne nie powinny być przechowywane w środowisku.
Aby przechowywać klucze interfejsu API Firebase (które nie są tajne), po prostu umieść je w kodzie.
Jeśli używasz Firebase Admin SDK w Cloud Functions, nie musisz jawnie podawać danych logowania konta usługi, ponieważ Admin SDK może je automatycznie uzyskać podczas inicjowania.
Jeśli wywołujesz interfejsy Google i Google Cloud API, które wymagają danych logowania konta usługi , biblioteka Google Auth dla Node.js może pobrać te dane z domyślnych danych logowania aplikacji , które są automatycznie wypełniane w Cloud Functions.
Aby udostępnić klucze prywatne i dane logowania do usług innych niż Google w Cloud Functions, użyj Secret Manager.
Szyfrowanie informacji poufnych
Jeśli nie możesz uniknąć przekazywania informacji poufnych do funkcji, musisz opracować własne rozwiązanie niestandardowe do szyfrowania tych informacji.
Proste funkcje są bezpieczniejsze. Jeśli potrzebujesz złożoności, rozważ użycie Cloud Run
Staraj się, aby funkcje były jak najprostsze i jak najbardziej zrozumiałe. Złożoność funkcji może często prowadzić do trudnych do wykrycia błędów lub nieoczekiwanego zachowania.
Jeśli potrzebujesz złożonej logiki lub konfiguracji środowiska, rozważ użycie Cloud Run zamiast Cloud Functions.
Zarządzanie środowiskiem
Konfigurowanie projektów deweloperskich i testowych
Skonfiguruj osobne projekty Firebase do tworzenia, testowania i produkcji. Nie scalaj kodu klienta z wersją produkcyjną, dopóki nie zostanie on przetestowany w projekcie testowym.
Ograniczanie dostępu zespołu do danych produkcyjnych
Jeśli pracujesz w większym zespole, możesz ograniczyć konsekwencje błędów i naruszeń, ograniczając dostęp do danych produkcyjnych za pomocą predefiniowanych ról uprawnień lub niestandardowych ról uprawnień.
Jeśli Twój zespół używa Firebase Local Emulator Suite (zalecane) do tworzenia aplikacji, być może nie musisz przyznawać szerszego dostępu do projektu produkcyjnego.
Zarządzanie biblioteką
Uważaj na błędy w pisowni bibliotek lub nowych opiekunów
Podczas dodawania bibliotek do projektu zwróć szczególną uwagę na nazwę biblioteki i jej opiekunów. Biblioteka o podobnej nazwie do tej, którą chcesz zainstalować, może zawierać szkodliwy kod.
Nie aktualizuj bibliotek bez zrozumienia zmian
Przed uaktualnieniem zapoznaj się z dziennikami zmian wszystkich używanych bibliotek. Upewnij się, że uaktualnienie przynosi korzyści, i sprawdź, czy opiekun jest nadal zaufaną osobą.
Instalowanie bibliotek watchdog jako zależności deweloperskich lub testowych
Użyj biblioteki takiej jak Snyk, aby przeskanować projekt pod kątem niezabezpieczonych zależności.
Konfigurowanie monitorowania Cloud Functions; sprawdzanie go po aktualizacjach biblioteki
Jeśli używasz pakietu Cloud Functions Logger SDK, to możesz monitorować nietypowe zachowania, w tym zachowania spowodowane aktualizacjami biblioteki, i otrzymywać o nich alerty.