Le chiavi Google in chiaro sul sito possono aprire anche Gemini: cosa fare subito

Per più di dieci anni gli sviluppatori hanno considerato le chiavi di Google con prefisso AIza come uno strumento non eccessivamente “delicato”: sono esposte nel front-end, cioè nel codice visibile lato utente del sito o dell’applicazione, servono a identificare il progetto e ad attribuire correttamente i costi, ma non sono trattate come vere credenziali di accesso, in quanto non permettono di consultare dati privati o riservati.

La situazione è cambiata con l’arrivo di Gemini: la stessa tipologia di chiave utilizzata da servizi “pubblici” come Maps e Firebase può diventare, senza segnali evidenti, un lasciapassare verso endpoint che gestiscono file caricati, contenuti in cache e chiamate LLM a consumo.

Il passaggio è importante anche in chiave storica. La guida ufficiale di Firebase ha a lungo ribadito che le chiavi API non sono segreti e la documentazione di Maps JavaScript ha normalizzato l’idea di incollarle direttamente nell’HTML. Nel frattempo la piattaforma ha esteso le superfici di API legate all’AI generativa, mantenendo la stessa forma di credenziale.

A fine 2025, un’analisi su larga scala del dataset Common Crawl di novembre 2025 (2,29 miliardi di pagine Web, 378 TB di contenuto non compresso) ha mostrato quanto la combinazione sia esplosiva: migliaia di chiavi esposte sul Web risultavano valide anche per chiamate Gemini, con un impatto che unisce rischio dati e rischio costi.

Fonte dell’immagine: Truffle Security

Google: una sola forma di chiave, due significati operativi

Gli esperti di Truffle Security, che hanno portato a galla il problema, confermano che il punto nodale risiede proprio nell’uso di un unico formato di chiave, riconoscibile dal prefisso AIza, per due scopi concettualmente diversi.

Nel mondo “classico” di molte API Google, la chiave funge soprattutto da identificatore: abilita la contabilizzazione, applica quote e controlli antiabuso, ma è progettata per vivere in contesti dove può essere letta (ad esempio nel codice JavaScript distribuito a ogni visitatore).

Il modello regge finché l’insieme di API autorizzate dalla chiave resta confinato a servizi che non espongono dati privati dell’impresa o del professionista, o in cui l’esposizione è gestita da restrizioni applicative. È il motivo per cui, per anni, la documentazione ha tollerato l’inclusione di chiavi nel client e ha puntato su limitazioni aggiuntive.

In Google Cloud, ad esempio, una chiave può essere vincolata a un browser tramite HTTP referrer allow-list oppure a chiamate server-side tramite IP e può essere ulteriormente limitata a specifiche API abilitate sul progetto.

Gemini e l’espansione retroattiva dei privilegi

L’elemento di rottura arriva quando sullo stesso progetto viene abilitata l’API di Gemini, denominata Generative Language API, all’interno del catalogo dei servizi.

A quel punto, chiavi preesistenti create per altri usi possono diventare immediatamente valide per endpoint Gemini senza un flusso di conferma, senza una notifica e senza una separazione automatica tra “chiavi pubblicabili” e “chiavi segrete”.

Il risultato è una vera espansione retroattiva dei privilegi: una chiave nata come token “benigno” per un widget di mappa può trasformarsi in credenziale capace di interrogare risorse AI associate allo stesso progetto.

La dinamica è aggravata dal comportamento di default nella console: molte chiavi, se create senza configurazioni aggiuntive, risultano “Unrestricted”, quindi potenzialmente utilizzabili con qualunque API abilitata sul progetto. Anche quando l’interfaccia avvisa del rischio di uso non autorizzato, l’impostazione iniziale resta ampia; la riduzione dei permessi è demandata all’operatore e spesso arriva dopo che la chiave è già stata distribuita nel codice client.

Endpoint coinvolti e perché sono sensibili

La superficie di rischio non riguarda solo la generazione di testo. La documentazione della Gemini API espone endpoint che permettono di enumerare i modelli disponibili e, soprattutto, di gestire risorse parte integrante progetto: file e contenuti in cache.

Il tema file è delicato perché il servizio supporta flussi in cui documenti e media sono caricati e riutilizzati in chiamate successive. La documentazione della Files API indica limiti espliciti: fino a 20 GB per progetto, 2 GB per singolo file, conservazione per 48 ore.

Anche se non è previsto il download diretto dei contenuti tramite la stessa API, i metadati e gli URI associati rappresentano già un’informazione sensibile, soprattutto se collegati a flussi di lavoro applicativi o a documenti caricati per l’elaborazione (ad esempio PDF). A questi si aggiunge la cache esplicita: l’endpoint di caching usa risorse chiamate cachedContents e consente creazione e listing.

Dal rischio di esposizione al rischio economico

Un attacco non richiede compromissione dell’infrastruttura della vittima. Basta ottenere la chiave, spesso con un semplice “View Source” (CTRL+U nel browser) o tramite scraping di asset JavaScript, e inviare chiamate REST verso gli endpoint AI.

Da quel momento il rischio si biforca: da un lato l’accesso a risorse e metadati legati al progetto (file e cache), dall’altro l’abuso con impatti diretti sulla fatturazione. Le chiamate ai modelli sono a consumo; un attore malevolo può generare carichi elevati, saturare quote e produrre addebiti significativi, con impatto immediato sulla continuità del servizio e sul budget.

La ricerca pubblicata da Truffle Security descrive una scansione su milioni di siti basata sul dataset Common Crawl di novembre 2025 e identifica 2.863 chiavi “live” utilizzabili.

Tra i casi citati compaiono organizzazioni di grandi dimensioni e persino chiavi presenti su proprietà pubbliche di Google, con evidenze storiche tramite archivi Web che mostrano la pubblicazione della chiave già nel febbraio 2023, quindi prima dell’esistenza operativa della stessa API Gemini.

Mitigazioni operative immediate e difese strutturali

La prima azione è mettere in campo è capire subito dove è abilitata l’API di Gemini: in Google Cloud Console il controllo passa da “APIs & Services” e dal pannello delle API abilitate, cercando la Generative Language API su ogni progetto. Se il servizio non è abilitato, il vettore specifico descritto non è attivo; se è abilitato, è necessario passare alle credenziali e verificare chiavi “Unrestricted” o chiavi che includono esplicitamente l’API AI tra i servizi consentiti.

La seconda azione è separare i confini. Il suggerimento più robusto, quando possibile, è usare progetti diversi: un progetto dedicato a componenti client-side pubblici (ad esempio una mappa su sito) e un progetto dedicato alle chiamate AI server-side. In questo modo la semplice abilitazione di una nuova API non può “toccare” chiavi pubblicate altrove, perché non condividono lo stesso spazio di credenziali. La separazione può sembrare un costo organizzativo, ma è un’operazione essenziale.

La terza azione consiste nel ridurre l’esposizione: le linee guida Gemini raccomandano di non usare chiavi in produzione lato client e di spostare le chiamate su server dove la chiave resta confidenziale. Per i casi in cui l’accesso client-side è inevitabile, la documentazione menziona l’uso di ephemeral tokens per la Live API, proprio per abbassare l’impatto di un’eventuale estrazione.

In parallelo, la rotazione diventa un requisito: se una chiave con accesso Gemini è finita in un asset pubblico o in un repository, la risposta corretta non è “nasconderla”, ma sostituirla e invalidare la precedente.

La quarta azione riguarda la dimensione economica: anche con controlli tecnici, un abuso può avvenire e generare costi. Qui entrano in gioco budget e avvisi di fatturazione: il cloud billing permette di configurare budget, alert via email e persino notifiche programmatiche, utili per attivare automatismi di contenimento.