Guida
È sicuro rendere pubblica la tua chiave API Firebase?
3 novembre 2026 · 4 min di lettura
Firebase dice che le sue chiavi API possono stare nel tuo codice, ed è così, a due condizioni. Cosa può fare qualcuno con la tua chiave, cosa no, e come chiudere la falla.
La risposta breve
Sì. Firebase scrive "API keys for Firebase services are OK to include in code or checked-in config files." (le chiavi API dei servizi Firebase possono stare nel codice o in file di configurazione versionati) (Chiavi API Firebase). La tua configurazione web, google-services.json e GoogleService-Info.plist contengono la chiave, e ogni utente della tua app ne ha una copia.
Ma pubblica non vuol dire innocua. La chiave è sicura quando valgono due cose: può chiamare solo le API che servono alla tua app, e i tuoi dati sono protetti da Security Rules e App Check. Se ne manca una, la chiave diventa la porta d'ingresso alla tua fattura.
Perché è pubblica per scelta
La maggior parte delle chiavi API funziona come una password. Quelle di Firebase no: dicono a quale progetto è destinata una richiesta, così Google può applicare quote e fatturazione. Firebase spiega che "API keys for Firebase services are not used to control access to backend resources" (le chiavi API dei servizi Firebase non servono a controllare l'accesso alle risorse del backend). Con le sue parole: "None of the Firebase-related APIs use an API key as authorization for calling the API." (nessuna delle API legate a Firebase usa una chiave API come autorizzazione per chiamare l'API).
Chi può leggere o scrivere cosa lo decidono le Security Rules di Firebase, e quali app possono chiamare il tuo backend lo decide App Check. Per questo nascondere la chiave non serve a niente, e per questo Firebase avverte: "Don't rely only on restricting and/or obscuring your API keys." (non affidarti solo a limitare o nascondere le tue chiavi API). Tutto ciò che sta nel tuo frontend, variabili d'ambiente comprese, finisce nel codice che scaricano i tuoi utenti.
Cosa non può fare qualcuno con la tua chiave
- Leggere o modificare i tuoi dati. No, se le tue Security Rules controllano chi sta chiedendo. La chiave non scavalca le regole.
- Accedere come uno dei tuoi utenti. No, senza le credenziali di quell'utente.
- Chiamare API che la chiave non può chiamare. Con le restrizioni delle API, ogni altra API la rifiuta.
Cosa può farci qualcuno
- Chiamare qualsiasi API che la chiave consente, a tue spese. Una chiave senza restrizioni funziona con tutte le API attive nel progetto. Se Gemini, Maps o un'altra API a pagamento è attiva, uno sconosciuto può usarla e paghi tu. È così che è nata una fattura Gemini da 82.314 $.
- Martellare i tuoi endpoint di accesso. Firebase avverte che qualcuno con la tua chiave potrebbe "use your API key to access Firebase's authentication endpoints and make authentication requests against your project." (usare la tua chiave API per accedere agli endpoint di autenticazione di Firebase e fare richieste di autenticazione al tuo progetto). Per esempio, per provare password. Consiglia di abbassare la quota della Identity Toolkit API al tuo traffico normale.
- Usare il tuo backend dal proprio codice. Con la tua configurazione, uno script può leggere e scrivere tutto ciò che le tue regole consentono, e far salire letture e scritture intanto. È App Check a distinguere la tua app da quello script.
Come rendere sicura una chiave pubblica
- Limita le sue API. Consenti solo le API che la tua app chiama. Passo per passo: come limitare una chiave API Firebase.
- Mai una chiave non Firebase nel client. Una chiave della Gemini Developer API, una chiave server di Maps o un file di service account sono veri segreti. Firebase dice che la chiave Gemini "should never be included in your code or configuration files." (non deve mai essere inclusa nel tuo codice né nei file di configurazione).
- Chiudi le tue Security Rules. Niente
allow read, write: if truefuori da un progetto di test. - Attiva App Check. È lo strumento di Firebase per "preventing unauthorized clients from accessing your backend resources" (impedire a client non autorizzati di accedere alle risorse del tuo backend), anche se Firebase ammette che "prevents some, but not all, abuse vectors" (blocca alcuni vettori di abuso, ma non tutti).
- Limita il volume. Una quota giornaliera sulle API a pagamento e un budget che fa partire un'azione, non solo un'email, contengono quanto può costare una falla sfuggita (come limitare la spesa su Firebase).
