Elenco di controllo per la sicurezza di Firebase

Per mantenere le risorse Firebase e la gestione la sicurezza dei dati, segui queste linee guida. Non tutti gli articoli sono necessariamente conformi ai tuoi requisiti, ma mantieni a mente 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 attacchi DoS (Denial of Service), configura monitoraggio e avvisi per Cloud Firestore, Realtime Database, Cloud Storage e Hosting

Se sospetti un attacco alla tua applicazione, contattare l'assistenza il prima possibile per comunica loro cosa sta succedendo.

Attiva App Check

Per assicurarti che solo le tue app possano accedere ai servizi di backend, abilita Firebase App Check per ogni servizio che lo supporta.

Configurare Cloud Functions per adattarsi al traffico normale

Cloud Functions scala automaticamente per soddisfare le esigenze della tua app, ma nel in caso di attacco, può comportare una fattura salatissima. 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 presenta picchi di richieste, spesso le quote vengono attivate e per limitare il traffico verso la tua applicazione. Assicurati di monitorare Dashboard per utilizzo e fatturazione, ma puoi anche impostare avvisi relativi al budget sul 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 eseguire accidentalmente una DOS durante lo sviluppo Cloud Functions: ad esempio, creando un ciclo trigger-scrittura infinito. Per evitare che questi errori influiscano sui servizi in tempo reale, esegui lo sviluppo con Firebase Local Emulator Suite.

Se per errore esegui 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 hai bisogno di presentare il risultato di una funzione in tempo reale, puoi mitiga il traffico illecito elaborando i risultati in batch: pubblica a un Pub/Sub ed elaborare i risultati a intervalli regolari con un funzione programmata.

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 è necessario trattare le chiavi API per i servizi Firebase come segreti e incorporarle in sicurezza nel codice client. Scopri di più su Chiavi API per Firebase.

Configurare le limitazioni relative alle chiavi API

Come ulteriore deterrente contro un utente malintenzionato che tenta di utilizzare la tua chiave API per di spoofing, puoi aggiungere Restrizioni relative alle chiavi API per limitare le chiavi API ai client dell'app e alle API che utilizzi.

Mantieni segrete FCM chiavi server

A differenza delle chiavi API per i servizi Firebase, FCM chiavi server (utilizzate dal API HTTP FCM precedente) sono sensibili e devono essere mantenuti segreti.

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 tenuti segreti.

Firebase Security Rules

Inizializzare le regole in modalità di produzione o di blocco

Quando configuri Cloud Firestore, Realtime Database e Cloud Storage, inizializza la tua regole di sicurezza per negare completamente l'accesso per impostazione predefinita e aggiungere regole che concedono l'accesso a di risorse specifiche durante lo sviluppo dell'app.

Utilizza una delle impostazioni predefinite per le nuove istanze di Cloud Firestore (produzione (modalità di blocco) e Realtime Database (modalità di blocco). Per Cloud Storage, inizia con un token 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 pre-lancio dell'attività. Devi invece scrivere le regole di sicurezza mentre scrivi l'app, trattandole come un schema del database: ogni volta che devi utilizzare un nuovo tipo di documento o una nuova struttura del percorso, e scrivere 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. Creare JWT personalizzati da un ambiente attendibile, quindi passa i token al 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, vedi nel post del blog, Esegui l'autenticazione con Firebase utilizzando Okta.

Autenticazione gestita: i provider OAuth 2.0 sono i più sicuri

Se utilizzi le funzioni di autenticazione gestita di Firebase, il protocollo OAuth 2.0 / OpenID Le opzioni del provider di connessione (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 dell'API Identity Toolkit nella console Google Cloud.

Autenticazione email-password: attiva la protezione dall'enumerazione delle email

Se utilizzi il servizio di autenticazione tramite password email gestito di Firebase, attivare la protezione dall'enumerazione delle email, impedendo ai malintenzionati di abusare degli endpoint di autenticazione del 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 dell'accesso, puoi aggiungere il supporto dell'autenticazione a più fattori. eseguendo l'upgrade a Google Cloud Identity Platform. Il codice di Firebase Authentication esistente continuerà a funzionare dopo l'upgrade.

Autenticazione anonima

Utilizza solo l'autenticazione anonima per le operazioni preliminari 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 dell'utente.

Convertire gli utenti a un altro metodo di accesso se vogliono che i loro dati siano su altri dispositivi

I dati di autenticazione anonimi non verranno mantenuti se l'utente cancella i dati locali archiviazione o cambia dispositivo. Se hai bisogno di mantenere i dati dopo i riavvii dell'app su un solo dispositivo, convertire l'utente in un account permanente.

Utilizza regole di sicurezza che richiedono che gli utenti siano passati a un provider di accesso o che abbiano verificato l'indirizzo email

Chiunque può creare un account anonimo nel tuo progetto. Di conseguenza, di proteggere tutti i dati non pubblici con regole di sicurezza che richiedono metodi di accesso o indirizzi email verificati specifici.

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 ospitata autonomamente, si utilizzano le variabili di ambiente per contenere e sensibili come le chiavi private. Non farlo in Cloud Functions. Perché Cloud Functions riutilizza ambienti tra le chiamate di funzione, le informazioni sensibili non archiviati 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 per fornire esplicitamente le credenziali dell'account di servizio, poiché Admin SDK li può acquisire automaticamente durante l'inizializzazione.

  • Se chiami le API Google e Google Cloud che richiedono un account di servizio credenziali, la libreria Google Auth per Node.js può recuperare queste credenziali dal credenziali predefinite dell'applicazione, che vengono compilati automaticamente in Cloud Functions.

  • Per rendere disponibili sul tuo account chiavi e credenziali private per i servizi non Google Cloud Functions, usa Secret Manager

Cripta le informazioni sensibili

Se non puoi evitare di trasmettere informazioni sensibili alle tue funzioni, creare una soluzione personalizzata per criptare le informazioni,

Le funzioni semplici sono più sicure. se hai bisogno di complessità, prendi in considerazione Cloud Run

Cerca di mantenere le tue funzioni il più basilari e comprensibili possibile. Complessità delle tue funzioni possono spesso portare a bug difficili da individuare o comportamenti imprevisti.

Se hai bisogno di configurazioni logiche o di ambiente complesse, valuta l'utilizzo Cloud Run anziché Cloud Functions.

Gestione dell'ambiente

Configurare i progetti di sviluppo e di 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 nel progetto di staging.

Limitare l'accesso del team ai dati di produzione

Se lavori con un team più grande, puoi mitigare le conseguenze degli errori e violazioni limitando l'accesso ai dati di produzione utilizzando ruoli IAM predefiniti o ruoli IAM personalizzati.

Se il tuo team utilizza la Firebase Local Emulator Suite (consigliato) per lo sviluppo, potrebbe non essere necessario concedere un accesso più ampio al progetto di produzione.

Gestione delle biblioteche

Fare attenzione a errori ortografici nelle biblioteche o a nuovi operatori di manutenzione

Quando aggiungi librerie al progetto, presta particolare attenzione al nome del e i suoi manutentori. Una raccolta con un nome simile a quella che intendi installare potrebbe contenere codice dannoso.

Non aggiornare le librerie senza aver compreso le modifiche

Controlla i log delle modifiche delle eventuali librerie che utilizzi prima di eseguire l'upgrade. Assicurati che l'upgrade aggiunge valore e verifica che chi gestisce la manutenzione sia ancora una parte la fiducia degli utenti.

Installare le librerie watchdog come dipendenze di sviluppo o test

Utilizza una libreria come Snyk per eseguire la scansione del progetto per le dipendenze non sicure.

Configura il monitoraggio per Cloud Functions; controlla dopo gli aggiornamenti della raccolta

Se utilizzi SDK del logger Cloud Functions, quindi puoi monitorarli e ricevere avvisi di comportamenti anomali, ad esempio causati da aggiornamenti della raccolta.