Google 致力于为黑人社区推动种族平等。查看具体举措

Elenco di controllo per la sicurezza di Firebase

Per proteggere le tue risorse Firebase e i dati dei tuoi utenti, segui queste linee guida. Non tutti gli elementi si applicano necessariamente alle tue esigenze, ma tienili a mente mentre sviluppi la tua app.

Evita il traffico abusivo

Imposta monitoraggio e avvisi per i servizi di backend

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 far sapere loro cosa sta succedendo.

Abilita controllo app App

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

Configura le tue funzioni cloud per adattarsi al traffico normale

Cloud Functions si ridimensiona automaticamente per soddisfare le esigenze della tua app, ma in caso di attacco questo può significare un grosso conto. Per evitare ciò, puoi limitare il numero di istanze simultanee di una funzione in base al traffico normale per la tua app.

Imposta un avviso per essere avvisato quando i limiti sono quasi raggiunti

Se il tuo servizio ha picchi di richieste, spesso entrano in gioco le quote e limitano automaticamente il traffico alla tua applicazione. Assicurati di monitorare la dashboard di 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.

Prevenire gli auto-DOS: testare le funzioni in locale con gli emulatori

Può essere facile eseguire il DOS accidentalmente durante lo sviluppo di Cloud Functions: ad esempio, creando un ciclo infinito di scrittura di trigger. Puoi evitare che questi errori influiscano sui servizi live eseguendo lo sviluppo con la suite di emulatori Firebase .

(E se firebase deploy --only functions accidentalmente il DOS da solo, annulla la distribuzione della tua funzione rimuovendola da index.js quindi eseguendo firebase deploy --only functions .)

Laddove la reattività in tempo reale è meno importante, la struttura funziona in modo difensivo

Se non è necessario presentare il risultato di una funzione in tempo reale, è possibile ridurre il traffico illecito elaborando i risultati in batch: pubblicare i risultati in un argomento Pub/Sub ed elaborare 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, cosa che avviene tramite Firebase Security Rules . 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 .

Imposta l'ambito della chiave API

Come ulteriore deterrente contro un utente malintenzionato che tenti di utilizzare la tua chiave API per falsificare le richieste, puoi creare chiavi API con ambito per i client della tua 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 produzione o in modalità 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 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 di 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 la tua app, come una sorta di attività pre-lancio. Invece, scrivi le 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 per i test di unità 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: coniare JWT da un ambiente attendibile (lato server)

Se disponi già di un sistema di accesso sicuro, sia esso un sistema personalizzato o 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, consulta il post del blog Autentica 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 provider (a seconda della tua base di 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 email-password gestito di Firebase, riduci la quota predefinita degli endpoint identitytoolkit.googleapis.com per prevenire attacchi di forza bruta. Puoi farlo dallapagina dell'API in Google Cloud Console .

Esegui l'upgrade a Cloud Identity Platform per l'autenticazione a più fattori

Per una maggiore sicurezza all'accesso, puoi aggiungere il supporto per l'autenticazione a più fattori eseguendo l'upgrade a Cloud Identity Platform . Il tuo codice di autenticazione Firebase esistente continuerà a funzionare dopo l'upgrade.

Autenticazione anonima

Usa solo l'autenticazione anonima per il warm onboarding warm

Usa 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 anonima non verranno mantenuti se l'utente cancella l'archiviazione locale o cambia dispositivo. Se devi mantenere i dati oltre il riavvio dell'app su un singolo dispositivo, converti l'utente in un account permanente .

Utilizza regole di sicurezza che richiedono che gli utenti si siano convertiti in un provider di accesso o abbiano verificato la loro 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 staging

Imposta progetti Firebase separati per lo sviluppo, la messa in scena e la produzione. Non unire il codice client alla produzione finché non è stato testato rispetto al progetto di staging.

Limitare l'accesso del team ai dati di produzione

Se lavori con un team più ampio, 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 ai suoi manutentori. Una libreria con 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 parte di cui ti fidi.

Installa le librerie watchdog come dipendenze di sviluppo o test

Usa 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 del logger di Cloud Functions , puoi monitorare ed essere avvisato di comportamenti insoliti, inclusi comportamenti causati 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, usi le variabili di ambiente per contenere informazioni riservate 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 memorizzare le chiavi API di Firebase, che non sono segrete , è sufficiente incorporarle nel codice.
  • Se stai utilizzando l'SDK di amministrazione di Firebase in una funzione cloud, non è necessario fornire esplicitamente le credenziali dell'account di servizio, poiché l'SDK può acquisirle automaticamente durante l'inizializzazione.
  • Se stai chiamando le API di 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 compilate automaticamente in Cloud Functions.
  • Per rendere le chiavi e le credenziali private per i servizi non Google disponibili per le tue Cloud Functions, utilizza Cloud Secret Manager .

Cripta le informazioni sensibili

Se non puoi evitare di trasmettere informazioni sensibili alla tua funzione cloud, devi creare una 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 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 complesse di logica o ambiente, considera l'utilizzo di Cloud Run invece di Cloud Functions.