Per proteggere le risorse Firebase e i dati degli utenti, segui queste linee guida. Non tutti gli elementi si applicheranno necessariamente ai tuoi requisiti, ma tienili presenti durante lo sviluppo dell'app.
Evitare il traffico illecito
Configurare il monitoraggio e gli avvisi per i servizi di backend
Per rilevare il traffico illecito, ad esempio gli attacchi Denial of Service (DoS), configura il monitoraggio e gli avvisi per Cloud Firestore, Realtime Database, Cloud Storage e Hosting
Se sospetti un attacco alla tua applicazione, contatta l'assistenza il prima possibile per comunicare cosa sta succedendo.
Attivare App Check
Per assicurarti che solo le tue app possano accedere ai servizi di backend, attiva Firebase App Check per ogni servizio che lo supporta.
Configura il tuo Cloud Functions per la scalabilità in base al traffico normale
Cloud Functions esegue automaticamente lo scale up per soddisfare le esigenze della tua app, ma in caso di attacco, questo può comportare una fattura elevata. Per evitare questo problema, puoi limitare il numero di istanze simultanee di una funzione in base al traffico normale della tua app.
Configurare gli avvisi per ricevere una notifica quando i limiti sono quasi raggiunti
Se il tuo servizio registra picchi di richieste, spesso le quote verranno applicate e il traffico verso la tua applicazione verrà limitato automaticamente. Assicurati di monitorare la dashboard Utilizzo e fatturazione, ma puoi anche impostare avvisi di budget sul tuo progetto per ricevere una notifica quando l'utilizzo delle risorse supera le aspettative.
Evitare gli auto-DoS: testare le funzioni in locale con gli emulatori
Durante lo sviluppo Cloud Functions è facile eseguire accidentalmente un attacco DoS, ad esempio creando un loop di scrittura-trigger infinito. Puoi evitare che questi errori influiscano sui servizi live eseguendo lo sviluppo con il Firebase Local Emulator Suite.
Se esegui accidentalmente un attacco DoS, annulla il deployment della funzione eliminandola
da index.js e poi eseguendo
firebase deploy --only functions
Se la reattività in tempo reale è meno importante, struttura le funzioni in modo difensivo
Se non devi presentare il risultato di una funzione in tempo reale, puoi mitigare il traffico illecito elaborando i risultati in batch: pubblica i risultati in un Pub/Sub argomento ed elaborali a intervalli regolari con una funzione pianificata.
Comprendere le chiavi API
Le chiavi API per i servizi Firebase non sono segrete
Le chiavi API per i servizi Firebase identificano solo il tuo progetto e la tua app Firebase per questi servizi. L'autorizzazione viene gestita tramite Google Cloud autorizzazioni IAM, Firebase Security Rules, e Firebase App Check.
Tutte le chiavi API di cui è stato eseguito il provisioning da Firebase sono automaticamente limitate a API correlate a Firebase. Se la configurazione della tua app segue le linee guida riportate in questa pagina, le chiavi API limitate ai servizi Firebase non devono essere trattate come segreti ed è sicuro includerle nel codice o nei file di configurazione.
Configurare le limitazioni delle chiavi API
Se utilizzi le chiavi API per altri servizi Google, assicurati di applicare le limitazioni delle chiavi API per limitare l'ambito delle chiavi API ai client delle app e alle API che utilizzi.
Utilizza le chiavi API di cui è stato eseguito il provisioning da Firebase solo per le API correlate a Firebase. Se la tua app utilizza altre API (ad esempio, l'API Places per Maps o la Gemini Developer API), utilizza una chiave API separata e limitala all'API applicabile.
Mantenere segrete le chiavi server FCM
A differenza delle chiavi API per i servizi Firebase, le chiavi server FCM (utilizzate dalla vecchia API HTTP FCM) sono sensibili e devono essere mantenute segrete.
Mantenere segrete le chiavi del service account
A differenza delle chiavi API per i servizi Firebase, le chiavi private del service account (utilizzate dal Firebase Admin SDK) sono sensibili e devono essere mantenute segrete.
Firebase Security Rules
Inizializzare le regole in modalità di produzione o modalità di blocco
Quando configuri Cloud Firestore, Realtime Database e Cloud Storage, inizializza le Firebase Security Rules per negare per impostazione predefinita tutti gli accessi e aggiungi regole che concedono l'accesso a risorse specifiche durante lo sviluppo dell'app.
Utilizza una delle impostazioni predefinite per le nuove istanze di Cloud Firestore (modalità di produzione) e Realtime Database (modalità di blocco). Per Cloud Storage, inizia con una configurazione delle regole di sicurezza simile alla seguente:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Le regole di sicurezza sono uno schema; aggiungi regole quando aggiungi documenti
Non scrivere regole di sicurezza dopo aver scritto l'app, come una sorta di attività pre-lancio. Scrivi invece le regole di sicurezza mentre scrivi l'app, trattandole come uno schema di database: ogni volta che devi utilizzare un nuovo tipo di documento o una nuova struttura di percorso, scrivi prima la relativa regola di sicurezza.
Esegui test unitari delle regole di sicurezza con Local Emulator Suite; aggiungilo a CI
Per assicurarti che le regole di sicurezza siano al passo con lo sviluppo dell'app, esegui test unitari delle regole con Firebase Local Emulator Suite e aggiungi questi test alla pipeline CI. Consulta queste guide per Cloud Firestore e Realtime Database.
Autenticazione
Autenticazione personalizzata: generare JWT da un ambiente attendibile (lato server)
Se disponi già di un sistema di accesso sicuro, personalizzato o di terze parti, puoi utilizzare il sistema esistente per l'autenticazione con i servizi Firebase. Crea JWT personalizzati da un ambiente attendibile, quindi passa i token al client, che li utilizza per l' autenticazione (iOS+, Android, web, Unity, C++).
Per un esempio di utilizzo dell'autenticazione personalizzata con un provider di terze parti, consulta il post del blog, Eseguire l'autenticazione con Firebase utilizzando Okta.
Autenticazione gestita: i provider OAuth 2.0 sono i più sicuri
Se utilizzi le funzionalità di autenticazione gestita di Firebase, le opzioni del provider OAuth 2.0 / OpenID Connect (Google, Facebook e così via) sono le più sicure. Se possibile, dovresti supportare uno o più di questi provider (a seconda della tua base utenti).
Autenticazione con email e password: imposta una quota rigorosa per l'endpoint di accesso per impedire attacchi di forza bruta
Se utilizzi il servizio di autenticazione con email e password gestito da Firebase, limita la quota predefinita degli endpoint identitytoolkit.googleapis.com per impedire attacchi di forza bruta. Puoi farlo dalla
pagina
nella console Google Cloud.
Autenticazione con email e password: attiva la protezione dall'enumerazione delle email
Se utilizzi il servizio di autenticazione con email e password gestito da Firebase, attiva la protezione dall'enumerazione delle email, che impedisce agli attori illeciti di utilizzare gli endpoint di autenticazione del tuo progetto per indovinare i nomi degli account.
Esegui l'upgrade a Google Cloud Identity Platform per l'autenticazione a più fattori
Per una maggiore sicurezza durante l'accesso, puoi aggiungere il supporto per l'autenticazione a più fattori eseguendo l'upgrade a Google Cloud Identity Platform. Il codice Firebase Authentication esistente continuerà a funzionare dopo l'upgrade.
Autenticazione anonima
Utilizzare l'autenticazione anonima solo per l'onboarding a caldo
Utilizza l'autenticazione anonima solo per salvare lo stato di base degli utenti prima che accedano effettivamente. L'autenticazione anonima non sostituisce l'accesso degli utenti.
Convertire gli utenti a un altro metodo di accesso se vogliono avere i propri dati su altri dispositivi
I dati di autenticazione anonima non verranno mantenuti se l'utente cancella l'archiviazione locale o cambia dispositivo. Se devi conservare i dati oltre i riavvii dell'app su un singolo dispositivo, converti l'utente in un account permanente.
Utilizzare regole di sicurezza che richiedono agli utenti di aver eseguito la conversione a un provider di accesso o di aver verificato la propria email
Chiunque può creare un account anonimo nel tuo progetto. Tenendo presente questo aspetto, proteggi tutti i dati non pubblici con regole di sicurezza che richiedono metodi di accesso specifici o indirizzi email verificati.
Ad esempio:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Sicurezza Cloud Functions
Non inserire mai informazioni sensibili nelle variabili di ambiente
Spesso in un'app Node.js self-hosted, utilizzi le variabili di ambiente per contenere informazioni sensibili come le chiavi private. Non farlo in Cloud Functions. Poiché Cloud Functions riutilizza gli ambienti tra le invocazioni delle funzioni, le informazioni sensibili non devono essere archiviate nell'ambiente.
Per archiviare le chiavi API Firebase (che non sono segrete), incorporale nel codice.
Se utilizzi Firebase Admin SDK in Cloud Functions, non devi fornire esplicitamente le credenziali del service account, perché Admin SDK può acquisirle automaticamente durante l'inizializzazione.
Se chiami le API Google e Google Cloud che richiedono le credenziali del service account, la libreria di autenticazione Google per Node.js può ottenere queste credenziali dalle credenziali predefinite dell'applicazione, che vengono compilate automaticamente in Cloud Functions.
Per rendere disponibili le chiavi private e le credenziali per i servizi non Google a Cloud Functions, utilizza Secret Manager.
Criptare le informazioni sensibili
Se non puoi evitare di passare informazioni sensibili alle tue funzioni, devi trovare una soluzione personalizzata per criptare le informazioni.
Le funzioni semplici sono più sicure; se hai bisogno di complessità, valuta Cloud Run
Cerca di mantenere le funzioni il più semplici e comprensibili possibile. La complessità delle funzioni può spesso portare a bug difficili da individuare o a comportamenti imprevisti.
Se hai bisogno di una logica o di configurazioni di ambiente complesse, valuta la possibilità di utilizzare Cloud Run anziché Cloud Functions.
Gestione dell'ambiente
Configurare i progetti di sviluppo e gestione temporanea
Configura progetti Firebase separati per sviluppo, gestione temporanea e produzione. Non unire il codice client alla produzione finché non è stato testato rispetto al progetto di gestione temporanea.
Limitare l'accesso del team ai dati di produzione
Se lavori con un team più grande, puoi mitigare le conseguenze di errori e violazioni limitando l'accesso ai dati di produzione utilizzando i ruoli IAM predefiniti o i ruoli IAM personalizzati.
Se il tuo team utilizza Firebase Local Emulator Suite (consigliato) per lo sviluppo, potresti non dover concedere un accesso più ampio al progetto di produzione.
Gestione della raccolta
Fai attenzione agli errori di ortografia delle raccolte o ai nuovi responsabili della manutenzione
Quando aggiungi raccolte al tuo progetto, presta attenzione al nome della raccolta e ai suoi responsabili della manutenzione. Una raccolta con un nome simile a quella che intendi installare potrebbe contenere codice dannoso.
Non aggiornare le raccolte senza comprendere le modifiche
Esamina i log delle modifiche di tutte le raccolte che utilizzi prima di eseguire l'upgrade. Assicurati che l'upgrade aggiunga valore e verifica che il responsabile della manutenzione sia ancora una parte di cui ti fidi.
Installa le raccolte watchdog come dipendenze di sviluppo o di test
Utilizza una raccolta come Snyk per eseguire la scansione del progetto alla ricerca di dipendenze non sicure.
Configura il monitoraggio per Cloud Functions; controllalo dopo gli aggiornamenti delle raccolte
Se utilizzi l' Cloud FunctionsSDK logger, allora puoi monitorare e ricevere avvisi in caso di comportamenti insoliti, inclusi quelli causati dagli aggiornamenti delle raccolte.