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 ad esempio (DOS) attacchi di tipo denial-of-service, impostare il monitoraggio e allerta per la nube FireStore , in tempo reale del database , Cloud Storage , e Hosting

Se si sospetta un attacco alla propria applicazione, entrare in contatto con supporto al più presto possibile per far loro sapere cosa sta succedendo.

Abilita controllo app

Per contribuire a garantire solo le applicazioni possono accedere ai servizi di back-end, abilitare App Controllare per ogni servizio che lo sostiene.

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 questo, è possibile limitare il numero di istanze simultanee di una funzione in base al traffico normale per la vostra applicazione.

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 il vostro utilizzo e la fatturazione del cruscotto , ma è anche possibile impostare avvisi di bilancio sul vostro progetto per essere avvisati quando l'utilizzo delle risorse è superiore alle 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. È possibile evitare questi errori di influenzare i servizi in tempo reale facendo il vostro sviluppo con la suite di emulatore Firebase .

(E se lo fai accidentalmente DOS voi stessi, la vostra funzione undeploy rimuovendolo dal index.js poi eseguire firebase deploy --only functions .)

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

Se non avete bisogno di presentare il risultato di una funzione in tempo reale, è possibile attenuare contro il traffico abusivo elaborando i risultati in lotti: pubblicare i risultati a un pub / sub argomento, ed elaborare i risultati a intervalli regolari con una funzione di programma .

Comprendere le chiavi API

Le chiavi API per i servizi Firebase non sono segrete

Firebase chiavi usi API solo per identificare progetto Firebase della tua app per servizi Firebase, e non per controllare l'accesso ai database o dati di Cloud Storage, che avviene per mezzo Firebase Regole di sicurezza . Per questo motivo, non è necessario trattare le chiavi API per i servizi Firebase come segreti e puoi incorporarle in modo sicuro nel codice client. Scopri di più su chiavi API per Firebase .

Imposta l'ambito della chiave API

Come deterrente aggiuntivo contro un attaccante di tentare di utilizzare la chiave API per le richieste di spoofing, è possibile creare chiavi API limitate all'ambito di vostri clienti app .

Mantieni segrete le chiavi del server FCM

A differenza di chiavi API per servizi Firebase, le chiavi di server FCM (utilizzati dal retaggio FCM HTTP API ) sono sensibili e devono essere tenuti segreti.

Mantieni segrete le chiavi dell'account di servizio

Anche chiavi API differenza per i servizi di Firebase, servizio rappresentano chiavi private (utilizzate dal Admin SDK ) sono sensibili e devono essere tenuti segreti.

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 assicurarsi che le regole di sicurezza sono al passo con lo sviluppo della tua applicazione, unit test le regole con la suite di emulatore Firebase e aggiungere questi test per la pipeline CI. Vedere queste guide per cloud FireStore e in tempo reale del 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. Creare JWTs personalizzati da un ambiente di fiducia, quindi passare i gettoni al vostro cliente, che utilizza il token per l'autenticazione ( iOS + , Android , Web , Unità , C ++ ).

Per un esempio di utilizzo di autenticazione personalizzata con un provider di terze parti, vedere il post del blog, 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, 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 si utilizza il servizio di autenticazione tramite e-mail la password gestite da Firebase, stringere la quota predefinita dei identitytoolkit.googleapis.com endpoint per impedire attacchi di forza bruta. Puoi farlo dalla pagina di API in Google Cloud Console .

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

Per maggiore sicurezza sul cartello-in, è possibile aggiungere il supporto di autenticazione multi-fattore per l'aggiornamento a Cloud Platform Identity . Il tuo codice di autenticazione Firebase esistente continuerà a funzionare dopo l'upgrade.

Autenticazione anonima

Usa solo l'autenticazione anonima per il warm onboarding

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 avete bisogno di persistere dati oltre riavvia app su un singolo dispositivo, convertire l'utente a 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, proteggere tutti i dati non pubblici con regole di sicurezza che richiedono specifiche di accesso metodi 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 si lavora con una squadra più grande, è possibile attenuare le conseguenze di errori e violazioni limitando l'accesso ai dati di produzione utilizzando sia ruoli predefiniti o ruoli IAM personalizzato.

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

Utilizzare tale libreria come Snyk per eseguire la scansione del progetto per le dipendenze insicure.

Configurare il monitoraggio per le Funzioni; controllalo dopo gli aggiornamenti della libreria

Se si utilizza lo SDK cloud funzioni logger , è possibile monitorare ed essere avvisati di un comportamento insolito, compreso il comportamento causati da 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 fare questo nelle funzioni cloud. Poiché Cloud Functions riutilizza gli ambienti tra le chiamate di funzione, le informazioni riservate non devono essere archiviate nell'ambiente.

  • Per memorizzare Firebase chiavi API, che sono non segreto , basta inserire 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 chiami API di Google e Google Cloud che richiedono credenziali di account di servizio, la libreria di Google Auth per Node.js può ottenere queste credenziali delle credenziali predefinite delle applicazioni , che vengono compilati automaticamente nelle funzioni cloud.
  • Per fare le chiavi private e le credenziali per i servizi non-Google disponibili per le funzioni cloud, utilizzare cloud Segreto 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à, prendi in considerazione 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 si ha bisogno configurazioni di logica o di ambiente complesso, considerare l'utilizzo di cloud Run al posto delle funzioni cloud.