Per proteggere le risorse Firebase e i dati degli utenti, segui queste linee guida. Non tutti gli elementi si applicano necessariamente ai tuoi requisiti, ma tienili presente durante lo sviluppo dell'app.
Evitare il traffico illecito
Configura il monitoraggio e gli avvisi per i servizi di backend
Per rilevare il traffico illecito, ad esempio gli attacchi di tipo 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 informarla della situazione.
Attiva 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.
Configurare Cloud Functions per adattarsi al traffico normale
Cloud Functions si scala automaticamente per soddisfare le esigenze della tua app, ma in caso di attacco, la bolletta può essere salata. Per evitare questo problema, puoi limitare il numero di istanze simultanee di una funzione in base al traffico normale della tua app.
Configura gli avvisi per ricevere una notifica quando i limiti sono quasi raggiunti
Se il tuo servizio presenta picchi di richieste, spesso vengono applicate le quote e il traffico verso la tua applicazione viene automaticamente limitato. Assicurati di monitorare la dashboard Utilizzo e fatturazione, ma puoi anche impostare avvisi sul budget nel tuo progetto per ricevere una notifica quando l'utilizzo delle risorse supera le aspettative.
Evita gli attacchi di tipo DoS autoindotti: testa le funzioni localmente con gli emulatori
Può essere facile provocare un DOS accidentalmente durante lo sviluppoCloud Functions: ad esempio, creando un ciclo infinito di scrittura di trigger. Per evitare che questi errori influiscano sui servizi in tempo reale, esegui lo sviluppo con Firebase Local Emulator Suite.
Se per errore causi un attacco DOS, annulla il deployment della funzione eliminandola da index.js ed eseguendo firebase deploy --only functions
Se la reattività in tempo reale non è importante, struttura le funzioni in modo difensivo
Se non devi presentare il risultato di una funzione in tempo reale, puoi difenderti dal traffico illecito elaborando i risultati in batch: pubblica i risultati in un argomento Pub/Sub ed elaborali a intervalli regolari con una funzione pianificata.
Informazioni sulle 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 ai dati del database o di Cloud Storage, che viene eseguito utilizzando Firebase Security Rules. Per questo motivo, non devi trattare le chiavi API per i servizi Firebase come secret e puoi incorporarle tranquillamente nel codice client. Scopri di più sulle chiavi API per Firebase.
Configurare le limitazioni relative alle chiavi API
Come ulteriore deterrente contro un malintenzionato che tenta di utilizzare la tua chiave API per falsificare le richieste, puoi aggiungere restrizioni alle chiavi API per limitare l'ambito delle chiavi API ai client delle app e alle API che utilizzi.
Mantieni segrete le chiavi server FCM
A differenza delle chiavi API per i servizi Firebase, le chiavi di 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 degli account di servizio (utilizzate dal Firebase Admin SDK) sono sensibili e devono essere mantenute segrete.
Firebase Security Rules
Inizializza le regole in produzione o in modalità bloccata
Quando configuri Cloud Firestore, Realtime Database e Cloud Storage, inizializza Firebase Security Rules per negare tutto l'accesso per impostazione predefinita e aggiungi regole che concedano l'accesso a risorse specifiche durante lo sviluppo dell'app.
Utilizza una delle impostazioni predefinite per le nuove istanze di Cloud Firestore (modalità produzione) e Realtime Database (modalità bloccata). 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 le regole quando aggiungi i documenti
Non scrivere regole di sicurezza dopo aver scritto l'app, come una sorta di attività pre-lancio. Scrivi invece le regole di sicurezza man mano che 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 il test di unità delle regole di sicurezza con Local Emulator Suite; aggiungilo al CI
Per assicurarti che le regole di sicurezza siano al passo con lo sviluppo della tua app, esegui il test di unità 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: crea JWT da un ambiente attendibile (lato server)
Se hai già 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, poi 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 di utenti).
Autenticazione email e password: imposta una quota stretta per l'endpoint di accesso per impedire attacchi di forza bruta
Se utilizzi il servizio di autenticazione tramite email e password gestito da Firebase, rafforza la quota predefinita degli endpoint identitytoolkit.googleapis.com per impedire gli attacchi di brute force. Puoi farlo dalla pagina
API Identity Toolkit
nella console Google Cloud.
Autenticazione email/password: attiva la protezione di enumerazione email
Se utilizzi il servizio di autenticazione tramite email e password gestito da Firebase, attiva la protezione di enumerazione delle email, che impedisce ad attori malintenzionati di abusare degli endpoint di autenticazione del tuo progetto per indovinare i nomi degli account.
Eseguire l'upgrade a Google Cloud Identity Platform per l'autenticazione a più fattori
Per una maggiore sicurezza durante l'accesso, puoi aggiungere il supporto dell'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
Utilizza l'autenticazione anonima solo 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.
Convertire gli utenti a un altro metodo di accesso se vogliono avere i propri dati su altri dispositivi
I dati di autenticazione anonimi non vengono conservati se l'utente cancella l'archiviazione locale o cambia dispositivo. Se devi conservare i dati dopo i riavvii dell'app su un singolo dispositivo, converti l'utente in un account permanente.
Utilizza regole di sicurezza che richiedono agli utenti di aver eseguito la conversione a un provider di accesso o di aver verificato il proprio indirizzo email
Chiunque potrebbe creare un account anonimo nel tuo progetto. Tenendo presente questo, 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 di Cloud Functions
Non inserire mai informazioni sensibili nelle variabili di ambiente
Spesso in un'app Node.js auto-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 chiamate di funzione, le informazioni sensibili non devono essere memorizzate nell'ambiente.
Per memorizzare le chiavi API di Firebase (che non sono segrete), basta incorporarle nel codice.
Se utilizzi Firebase Admin SDK in un Cloud Functions, non è necessario fornire esplicitamente le credenziali dell'account di servizio, perché Admin SDK può acquisirle automaticamente durante l'inizializzazione.
Se chiami API di Google e Google Cloud che richiedono le credenziali dell'account di servizio, la libreria Google Auth per Node.js può recuperarle dalle credenziali predefinite dell'applicazione, che vengono compilate automaticamente in Cloud Functions.
Per rendere disponibili per il tuo Cloud Functions le chiavi private e le credenziali per i servizi non Google, utilizza Secret Manager.
Criptare le informazioni sensibili
Se non puoi evitare di passare informazioni sensibili alle tue funzioni, devi trovare una soluzione personalizzata per criptarle.
Le funzioni semplici sono più sicure. Se hai bisogno di complessità, valuta la possibilità di utilizzare 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 configurazioni di ambienti o logiche complesse, valuta la possibilità di utilizzare Cloud Run anziché Cloud Functions.
Gestione dell'ambiente
Configurare i progetti di sviluppo e di staging
Configura progetti Firebase distinti per lo sviluppo, la gestione temporanea e la produzione. Non unire il codice client alla produzione finché non è stato testato nel progetto di staging.
Limitare l'accesso del team ai dati di produzione
Se collabori con un team più grande, puoi mitigare le conseguenze di errori e violazioni limitando l'accesso ai dati di produzione utilizzando ruoli IAM predefiniti o ruoli IAM personalizzati.
Se il tuo team utilizza Firebase Local Emulator Suite (opzione consigliata) per lo sviluppo, potrebbe non essere necessario concedere un accesso più ampio al progetto di produzione.
Gestione della raccolta
Fai attenzione agli errori ortografici delle librerie o ai nuovi amministratori
Quando aggiungi librerie al progetto, presta molta attenzione al nome della libreria e ai relativi responsabili. Una raccolta con un nome simile a quella che intendi installare potrebbe contenere codice dannoso.
Non aggiornare le librerie senza comprendere le modifiche
Esamina i log delle modifiche di tutte le librerie che utilizzi prima di eseguire l'upgrade. Assicurati che l'upgrade aggiunga valore e verifica che il gestore sia ancora una persona di tua fiducia.
Installa le librerie di watchdog come dipendenze di sviluppo o test
Utilizza una libreria come Snyk per eseguire la scansione del progetto per rilevare le dipendenze non sicure.
Configura il monitoraggio per Cloud Functions; controlla dopo gli aggiornamenti della raccolta
Se utilizzi l'SDK di logger Cloud Functions, puoi monitorare e ricevere avvisi su comportamenti insoliti, inclusi quelli causati dagli aggiornamenti della libreria.