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 articoli si applicheranno necessariamente alle tue esigenze, ma tienili a mente mentre sviluppi la tua app.

Evita il traffico abusivo

Imposta il monitoraggio e gli avvisi per i servizi di back-end

Per rilevare il traffico abusivo, come gli attacchi DOS (Denial-of-Service), imposta il monitoraggio e gli avvisi per Cloud Firestore , database in tempo reale , 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 di back-end, abilita App Check per ogni servizio che lo supporta.

Configura le tue funzioni cloud per adattarle al traffico normale

Cloud Functions si ridimensiona automaticamente per soddisfare le richieste della tua app, ma in caso di attacco, questo può significare un conto molto alto. 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 sono quasi raggiunti

Se il tuo servizio ha picchi di richiesta, spesso si attivano 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 i self-DOS: testare le funzioni in locale con gli emulatori

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

(E se esegui accidentalmente il DOS, 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 mitigare il traffico abusivo 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 nei servizi Firebase e non per controllare l'accesso al database o ai dati di Cloud Storage, operazione che viene eseguita utilizzando le regole di sicurezza Firebase . Per questo motivo, non è necessario trattare le chiavi API per i servizi Firebase come segrete e puoi incorporarle in sicurezza nel codice client. Ulteriori informazioni sulle chiavi API per Firebase .

Imposta l'ambito della chiave API

Come ulteriore deterrente contro un utente malintenzionato che tenta di utilizzare la tua chiave API per falsificare le richieste, puoi creare chiavi API con ambito per i 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 tutto l'accesso per impostazione predefinita e aggiungi regole che concedono l'accesso a risorse specifiche durante lo sviluppo dell'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 l'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 unit test 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 affidabile (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 tuo 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 Autenticare con Firebase utilizzando Okta .

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

Se utilizzi le funzioni di autenticazione gestita di Firebase, le opzioni del provider OAuth 2.0/OpenID Connect (Google, Facebook, ecc.) sono le più sicure. Se possibile, dovresti supportare uno o più di questi fornitori (a seconda della tua base di utenti).

Autenticazione e-mail-password: imposta una quota ridotta per l'endpoint di accesso per prevenire attacchi di forza bruta

Se utilizzi il servizio di autenticazione della password e-mail gestito di Firebase, aumenta la quota predefinita degli endpoint identitytoolkit.googleapis.com per prevenire attacchi di forza bruta. Puoi farlo dalla pagina 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 dell'autenticazione a più fattori eseguendo l'aggiornamento a Cloud Identity Platform . Il codice di autenticazione Firebase esistente continuerà a funzionare dopo l'aggiornamento.

Autenticazione anonima

Usa l'autenticazione anonima solo per l'onboarding a caldo

Utilizzare 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 perdono il telefono

I dati di autenticazione anonimi non verranno mantenuti se l'utente cancella la memoria 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 le regole di sicurezza che richiedono agli utenti di essersi convertiti a un provider di accesso o di aver verificato la propria posta elettronica

Chiunque può 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 e-mail 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 messa in scena

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.

Limita 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 emulatori 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 gestori. Una libreria con nome simile a quella che intendi installare potrebbe contenere codice dannoso.

Non aggiornare le librerie senza aver compreso 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 controlla che il manutentore sia ancora una parte di cui ti fidi.

Installa le librerie di watchdog come dipendenze di sviluppo o test

Usa una libreria come Snyk per scansionare il tuo progetto alla ricerca di dipendenze non sicure.

Impostare il monitoraggio per le funzioni; controllalo dopo gli aggiornamenti della libreria

Se utilizzi l' SDK logger di Cloud Functions , puoi monitorare ed essere avvisato di comportamenti insoliti, incluso il comportamento causato dagli aggiornamenti della libreria.

Sicurezza della funzione cloud

Non inserire mai informazioni riservate nelle variabili di ambiente di una funzione cloud

Spesso in un'app Node.js auto-ospitata, usi le variabili di ambiente per contenere informazioni riservate come le chiavi private. Non farlo 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 stai utilizzando Firebase Admin SDK in una funzione cloud, non è necessario fornire in modo esplicito le credenziali dell'account di servizio, poiché l'SDK può acquisirle automaticamente durante l'inizializzazione.
  • Se chiami 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 automaticamente popolate in Cloud Functions.
  • Per rendere disponibili per le tue Cloud Functions chiavi private e credenziali per servizi non Google, utilizza Cloud Secret Manager .

Crittografa le informazioni sensibili

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