Per proteggere le tue risorse Firebase e i dati dei tuoi utenti, segui queste linee guida. Non tutti gli elementi si applicano 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 backend
Per rilevare il traffico abusivo, come 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 il supporto il prima possibile per fargli sapere cosa sta succedendo.
Abilita controllo app
Per garantire che solo le tue app possano accedere ai tuoi servizi backend, abilita App Check per ogni servizio che lo supporta.
Configura le tue Cloud Functions per adattarsi al traffico normale
Cloud Functions si adatta automaticamente per soddisfare le richieste della tua app, ma in caso di attacco ciò può comportare costi elevati. 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 vengono quasi raggiunti
Se il tuo servizio presenta picchi di richieste, spesso entrano in gioco le quote e limitano automaticamente il traffico verso la tua applicazione. Assicurati di monitorare il 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 gli auto-DOS: 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 infinito di trigger-scrittura. Puoi evitare che questi errori incidano sui servizi live eseguendo lo sviluppo con la suite di emulatori Firebase .
(E se esegui accidentalmente il DOS da solo, annulla la distribuzione della 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 nei servizi Firebase e non per controllare l'accesso al database o ai dati di Cloud Storage, operazione eseguita utilizzando le regole di sicurezza Firebase . Per questo motivo, non è necessario trattare le chiavi API per i servizi Firebase come segreti e puoi incorporarle in tutta sicurezza nel codice client. Ulteriori informazioni sulle chiavi API per Firebase .
Configura l'ambito della chiave API
Come ulteriore deterrente contro un utente malintenzionato che tenta di utilizzare la tua chiave API per eseguire lo spoofing delle richieste, puoi creare chiavi API con ambito limitato ai 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 legacy ) 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à produzione o bloccata
Quando configuri Cloud Firestore, Realtime Database e Cloud Storage, inizializza le regole di sicurezza per negare ogni accesso per impostazione predefinita e aggiungi regole che concedono l'accesso a risorse specifiche mentre sviluppi la tua app.
Questa è una delle impostazioni predefinite per le nuove istanze di Cloud Firestore (modalità di produzione) e Realtime Database (modalità bloccata). Scegli questa opzione quando configuri 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; 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 la tua app, trattandole come uno schema di database: ogni volta che devi utilizzare un nuovo tipo di documento o struttura di percorso, scrivi prima la sua regola di sicurezza.
Regole di sicurezza per test unitari con Emulator Suite; aggiungerlo a CI
Per assicurarti che le tue regole di sicurezza siano al passo con lo sviluppo della tua app, esegui un test unitario delle 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: conia 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 autenticarti 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, vedere il post del blog 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, ecc.) sono le più sicure. Se puoi, dovresti supportare uno o più di questi fornitori (a seconda della tua base utenti).
Autenticazione tramite password e-mail: imposta una quota ridotta per l'endpoint di accesso per prevenire attacchi di forza bruta
Se utilizzi il servizio di autenticazione tramite password e-mail gestito di Firebase, riduci la quota predefinita degli endpoint identitytoolkit.googleapis.com per prevenire attacchi di forza bruta. Puoi farlo dalla pagina dell'API nella console Google Cloud .
Autenticazione password e-mail: abilita la protezione dell'enumerazione e-mail
Se utilizzi il servizio di autenticazione gestito tramite password e-mail di Firebase, abilita la protezione dell'enumerazione e-mail , che impedisce ad autori 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 una maggiore sicurezza all'accesso, puoi aggiungere il supporto dell'autenticazione a più fattori eseguendo l'aggiornamento a Cloud Identity Platform . Il tuo codice di autenticazione Firebase esistente continuerà a funzionare dopo l'aggiornamento.
Autenticazione anonima
Utilizzare solo l'autenticazione anonima per l'onboarding a caldo
Utilizza l'autenticazione anonima solo 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 perderanno il telefono
I dati di autenticazione anonima non persisteranno se l'utente cancella la memoria locale o cambia dispositivo. Se devi rendere persistenti i dati anche dopo il riavvio dell'app su un singolo dispositivo, converti l'utente in un account permanente .
Utilizza regole di sicurezza che richiedono agli utenti di passare a un provider di accesso o di verificare la propria posta elettronica
Chiunque può creare un account anonimo nel tuo progetto. Tenendo questo a 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
Impostazione progetti di sviluppo e staging
Configura progetti Firebase separati per lo sviluppo, la gestione temporanea e la produzione. Non unire il codice client alla produzione finché non è stato testato rispetto al progetto di gestione temporanea.
Limita l'accesso del team ai dati di produzione
Se lavori con un team più numeroso, 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 emulazione 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 dei suoi manutentori. Una libreria con nome simile a quella che intendi installare potrebbe contenere codice dannoso.
Non aggiornare le librerie senza comprendere le modifiche
Controlla i registri delle modifiche di tutte le librerie che usi prima di eseguire l'aggiornamento. Assicurati che l'aggiornamento aggiunga valore e controlla che il manutentore sia ancora una persona di cui ti fidi.
Installa le librerie watchdog come dipendenze di sviluppo o test
Utilizza una libreria come Snyk per scansionare il tuo progetto alla ricerca di dipendenze non sicure.
Configurare il monitoraggio per le Funzioni; controllalo dopo gli aggiornamenti della libreria
Se utilizzi l' SDK di Cloud Functions logger , 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 Cloud Function
Spesso in un'app Node.js self-hosted si utilizzano 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 funzione, le informazioni riservate non devono essere archiviate nell'ambiente.
- Per archiviare le chiavi API Firebase, che non sono segrete , è sufficiente incorporarle nel codice.
- Se utilizzi Firebase Admin SDK in una Cloud Function, non è necessario fornire in modo esplicito le credenziali dell'account di servizio, perché l'SDK può acquisirle automaticamente durante l'inizializzazione.
- Se chiami Google e le API Google Cloud che richiedono credenziali dell'account di servizio, la libreria Google Auth per Node.js può ottenere queste credenziali dalle credenziali predefinite dell'applicazione , che vengono automaticamente compilate in Cloud Functions.
- Per rendere disponibili alle tue Cloud Functions chiavi private e credenziali per servizi non Google, utilizza Cloud Secret Manager .
Crittografare le informazioni sensibili
Se non puoi evitare di trasmettere informazioni sensibili alla tua Cloud Function, devi trovare la tua soluzione personalizzata per crittografare le informazioni.
Le funzioni semplici sono più sicure; se hai bisogno di complessità, considera Cloud Run
Cerca di mantenere le tue Funzioni Cloud quanto 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 configurazioni logiche o ambientali complesse, valuta la possibilità di utilizzare Cloud Run anziché Cloud Functions.