Per proteggere le tue risorse Firebase e i dati dei tuoi utenti, segui queste linee guida. Non tutti gli elementi si applicheranno necessariamente ai tuoi requisiti, ma tienili a mente mentre sviluppi la tua app.
Evita il traffico abusivo
Configura il monitoraggio e gli avvisi per i servizi di back-end
Per rilevare il traffico abusivo, come gli attacchi denial-of-service (DOS), configurare 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 informarli di ciò che sta accadendo.
Abilita il controllo dell'app
Per assicurarti che solo le tue app possano accedere ai tuoi servizi di back-end, abilita App Check per ogni servizio che lo supporta.
Configura le tue Cloud Functions in modo che si ridimensionino per il traffico normale
Cloud Functions scala automaticamente per soddisfare le esigenze della tua app, ma in caso di attacco, questo può significare un conto salato. Per evitare ciò, puoi limitare il numero di istanze simultanee di una funzione in base al traffico normale per la tua app.
Imposta avvisi per essere avvisato quando i limiti sono quasi raggiunti
Se il tuo servizio ha picchi di richieste, spesso le quote entrano in gioco e limitano automaticamente il traffico verso la tua applicazione. Assicurati di monitorare la tua dashboard di utilizzo e fatturazione , ma puoi anche impostare avvisi di budget sul tuo progetto per essere avvisato quando l'utilizzo delle risorse supera le aspettative.
Prevenire self-DOSes: testare le funzioni localmente con gli emulatori
Può essere facile eseguire accidentalmente il DOS durante lo sviluppo di Cloud Functions: ad esempio, creando un ciclo di scrittura trigger infinito. Puoi evitare che questi errori influiscano sui servizi live eseguendo il tuo sviluppo con la suite di emulatori Firebase .
(E se fai accidentalmente DOS tu stesso, annulla la distribuzione della tua funzione rimuovendola da index.js quindi eseguendo
Laddove la reattività in tempo reale è meno importante, la struttura funziona in modo difensivo
Se non hai bisogno di presentare il risultato di una funzione in tempo reale, puoi mitigare il traffico abusivo elaborando i risultati in batch: pubblica i risultati in un argomento Pub/Sub ed elabora i risultati a intervalli regolari con una funzione pianificata .
Comprendere le chiavi API
Le chiavi API per i servizi Firebase non sono segrete
Firebase utilizza le chiavi API solo per identificare il progetto Firebase della tua app per i servizi Firebase e non per controllare l'accesso al database o ai dati di Cloud Storage, operazione che viene eseguita utilizzando le regole di sicurezza di Firebase . Per questo motivo, non è necessario trattare le chiavi API per i servizi Firebase come segreti e puoi incorporarle in modo sicuro nel codice client. Ulteriori informazioni sulle chiavi API per Firebase .
Impostare l'ambito della chiave API
Come ulteriore deterrente contro un utente malintenzionato che tenta di utilizzare la tua chiave API per falsificare le richieste, puoi creare chiavi API con ambito per i tuoi client dell'app .
Mantieni segrete le chiavi del server FCM
A differenza delle chiavi API per i servizi Firebase, le chiavi del server FCM (utilizzate dall'API HTTP FCM precedente ) sono sensibili e devono essere mantenute segrete.
Mantieni segrete le chiavi dell'account di servizio
Inoltre, a differenza delle chiavi API per i servizi Firebase, le chiavi private dell'account di servizio (utilizzate da Admin SDK ) sono sensibili e devono essere mantenute segrete.
Regole di sicurezza
Inizializza le regole in modalità di produzione o bloccata
Quando configuri Cloud Firestore, Realtime Database e Cloud Storage, inizializza le regole di sicurezza per negare tutti gli accessi per impostazione predefinita e aggiungi regole che concedono l'accesso a risorse specifiche durante lo sviluppo dell'app.
Questa è una delle impostazioni predefinite per le nuove istanze di Cloud Firestore (modalità di produzione) e Realtime Database (modalità bloccata). Scegli questa opzione durante la configurazione di una nuova istanza del database.
Per Cloud Storage, inizia con una configurazione delle regole di sicurezza come la 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; aggiungere regole quando si aggiungono documenti
Non scrivere regole di sicurezza dopo aver scritto la tua app, come una sorta di attività pre-lancio. Invece, scrivi regole di sicurezza mentre scrivi la tua app, trattandole come uno schema di database: ogni volta che devi usare un nuovo tipo di documento o struttura di percorso, scrivi prima la sua regola di sicurezza.
Regole di sicurezza dei test unitari con Emulator Suite; aggiungilo a CI
Per assicurarti che le tue regole di sicurezza stiano al passo con lo sviluppo della tua app, testa le tue regole con la suite di emulatori Firebase e aggiungi questi test alla tua pipeline CI. Consulta queste guide per Cloud Firestore e Realtime Database .
Autenticazione
Autenticazione personalizzata: crea JWT da un ambiente attendibile (lato server).
Se disponi già di un sistema di accesso sicuro, che si tratti di un sistema personalizzato o di un servizio di terze parti, puoi utilizzare il sistema esistente per eseguire l'autenticazione con i servizi Firebase. Crea JWT personalizzati da un ambiente attendibile, quindi passa i token al tuo client, che utilizza il token 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 Autenticazione con Firebase tramite 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, ecc.) sono le più sicure. Dovresti supportare uno o più di questi fornitori se puoi (a seconda della tua base di utenti).
Autenticazione tramite password e-mail: imposta una quota ridotta per l'endpoint di accesso per impedire attacchi di forza bruta
Se utilizzi il servizio di autenticazione password email gestito di Firebase, riduci la quota predefinita degli endpoint identitytoolkit.googleapis.com per prevenire attacchi di forza bruta. Puoi farlo dalla pagina dell'API in Google Cloud Console .
Autenticazione email-password: abilita la protezione dell'enumerazione email
Se utilizzi il servizio di autenticazione con password e-mail gestito di Firebase, abilita la protezione dell'enumerazione e-mail , che impedisce agli attori malintenzionati di abusare degli endpoint di autenticazione del tuo progetto per indovinare i nomi degli account.
Esegui l'upgrade a Cloud Identity Platform per l'autenticazione a più fattori
Per maggiore sicurezza all'accesso, puoi aggiungere il supporto dell'autenticazione a più fattori eseguendo l'upgrade a Cloud Identity Platform . Il codice di autenticazione Firebase esistente continuerà a funzionare dopo l'aggiornamento.
Autenticazione anonima
Utilizzare solo l'autenticazione anonima per l'onboarding a caldo
Utilizzare solo l'autenticazione anonima per salvare lo stato di base per gli utenti prima che accedano effettivamente. L'autenticazione anonima non sostituisce l'accesso dell'utente.
Converti gli utenti in un altro metodo di accesso se vorranno i dati quando perdono il telefono
I dati di autenticazione anonimi non persisteranno se l'utente cancella l'archiviazione locale o cambia dispositivo. Se devi conservare i dati oltre il riavvio dell'app su un singolo dispositivo, converti l'utente in un account permanente .
Utilizza regole di sicurezza che richiedono agli utenti di essere convertiti a un provider di accesso o di aver verificato la propria posta elettronica
Chiunque può creare un account anonimo nel tuo progetto. Con questo in mente, proteggi tutti i dati non pubblici con regole di sicurezza che richiedono metodi di accesso specifici o indirizzi email verificati .
Per esempio:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Gestione dell'ambiente
Impostare progetti di sviluppo e messa in scena
Imposta progetti Firebase separati per lo sviluppo, la gestione temporanea e la produzione. Non unire il codice client alla produzione fino a quando non è stato testato rispetto al progetto di gestione temporanea.
Limita 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 ruoli predefiniti o ruoli IAM personalizzati.
Se il tuo team utilizza la suite di emulatori per lo sviluppo, potrebbe non essere necessario concedere un accesso più ampio al progetto di produzione.
Gestione della biblioteca
Fai attenzione agli errori di ortografia della libreria o ai nuovi manutentori
Quando aggiungi librerie al tuo progetto, presta molta attenzione al nome della libreria e ai suoi manutentori. Una libreria dal nome simile a quella che intendi installare potrebbe contenere codice dannoso.
Non aggiornare le librerie senza comprendere le modifiche
Esamina i registri delle modifiche di tutte le librerie che utilizzi prima di eseguire l'aggiornamento. Assicurati che l'aggiornamento aggiunga valore e verifica che il manutentore sia ancora una persona di cui ti fidi.
Installa librerie watchdog come dipendenze di sviluppo o test
Usa una libreria come Snyk per scansionare il tuo progetto alla ricerca di dipendenze non sicure.
Impostare il monitoraggio per le funzioni; controllalo dopo gli aggiornamenti della libreria
Se utilizzi l' SDK del logger di Cloud Functions , puoi monitorare ed essere avvisato di comportamenti insoliti, incluso il comportamento causato dagli aggiornamenti della libreria.
Sicurezza della funzione cloud
Non inserire mai informazioni sensibili nelle variabili di ambiente di una Funzione Cloud
Spesso in un'app Node.js self-hosted, utilizzi le variabili di ambiente per contenere informazioni sensibili come le chiavi private. Non eseguire questa operazione in Cloud Functions . Poiché Cloud Functions riutilizza gli ambienti tra le chiamate di funzioni, le informazioni riservate non devono essere archiviate nell'ambiente.
- Per archiviare le chiavi API di Firebase, che non sono secret , è sufficiente incorporarle nel codice.
- Se utilizzi l'SDK Firebase Admin in una funzione cloud, non è necessario fornire esplicitamente le credenziali dell'account di servizio, perché l'SDK può acquisirle automaticamente durante l'inizializzazione.
- Se chiami le API Google e Google Cloud che richiedono le credenziali dell'account di servizio, la libreria Google Auth per Node.js può ottenere queste credenziali dalle credenziali predefinite dell'applicazione , che vengono popolate automaticamente in Cloud Functions.
- Per rendere disponibili per Cloud Functions le chiavi private e le credenziali per i servizi non Google, utilizza Cloud Secret Manager .
Crittografare le informazioni sensibili
Se non puoi evitare di trasmettere informazioni sensibili alla tua Funzione Cloud, devi trovare la tua soluzione personalizzata per crittografare le informazioni.
Le funzioni semplici sono più sicure; se hai bisogno di complessità, prendi in considerazione Cloud Run
Cerca di mantenere le tue Cloud Functions il più semplici e comprensibili possibile. La complessità delle tue funzioni può spesso portare a bug difficili da individuare o comportamenti imprevisti.
Se hai bisogno di configurazioni logiche o ambientali complesse, prendi in considerazione l'utilizzo di Cloud Run invece di Cloud Functions.