Google API Keys: le chiavi pubbliche diventano credenziali sensibili

Feb 27, 2026 Redazione Approfondimenti, In evidenza, Minacce, Minacce, News, RSS, Tecnologia, Tecnologia, Vulnerabilità 0

L’introduzione di funzionalità di intelligenza artificiale generativa nelle piattaforme cloud sta ridefinendo il perimetro di sicurezza delle credenziali applicative. Un caso emblematico è stato scoperto dai ricercatori di Truffle Security Co. e riguarda l’ecosistema Google Cloud dove le tradizionali API key — storicamente considerate semplici identificatori di progetto — hanno acquisito nuovi privilegi con l’arrivo di Gemini. Il risultato è una superficie d’attacco inattesa, in cui migliaia di chiavi pubbliche possono essere sfruttate per accedere a dati privati, consumare risorse e generare costi anche elevati.

Un cambio di paradigma nella gestione delle API key

Per oltre un decennio Google ha comunicato in modo esplicito che le API key non erano né andavano trattate come segreti. La documentazione di servizi come Google Maps e Firebase invitava infatti gli sviluppatori a inserirle direttamente nel codice client o nelle pagine HTML, poiché il loro scopo principale era identificare il progetto ai fini di fatturazione e monitoraggio. Eventuali restrizioni, come l’allow-listing dei referer HTTP, venivano considerate controlli accessori e non meccanismi di autenticazione.

L’arrivo della Generative Language API, che abilita l’accesso a Gemini, ha però modificato radicalmente questa premessa. Quando l’API viene attivata in un progetto Google Cloud, tutte le API key esistenti associate a quel progetto possono ottenere automaticamente accesso agli endpoint sensibili di Gemini, senza notifiche, conferme o cambiamenti visibili nell’interfaccia di gestione. In altri termini, una chiave creata anni prima per un widget di Maps può trasformarsi silenziosamente in una credenziale capace di interrogare modelli generativi a nome di qualcun altro e accedere ai dati del progetto.

Questa dinamica introduce una forma di espansione retroattiva dei privilegi, in cui la sequenza temporale degli eventi diventa determinante. La chiave nasce come identificatore pubblico, l’API Gemini viene attivata successivamente e, senza alcun intervento dell’utente, la stessa chiave assume un ruolo autentico e sensibile. Il problema non è dunque una configurazione errata, ma un difetto architetturale legato a default permissivi e alla mancanza di separazione tra chiavi pubbliche e segrete.

Default insicuri e rischio di privilege escalation

Alla base della vulnerabilità vi è il fatto che Google utilizza un formato unico di API key (prefisso AIza…) per scenari con requisiti di sicurezza profondamente diversi. Quando una nuova chiave viene generata, la configurazione predefinita è “unrestricted”, rendendola valida per tutte le API abilitate nel progetto, incluse quelle generative. L’interfaccia segnala genericamente il rischio di uso non autorizzato, ma l’impostazione di default resta permissiva.

Questo scenario si allinea a due debolezze note: posture di sicurezza con default insicuri e assegnazione impropria dei privilegi. L’assenza di separazione tra chiavi pubbliche e segrete favorisce confusione operativa e compromissioni, mentre l’upgrade implicito dei privilegi applicato a chiavi già esposte in ambienti pubblici rappresenta una forma di trust escalation difficilmente individuabile dagli sviluppatori.

Lo scenario di attacco: scraping e accesso ai dati Gemini

Dal punto di vista operativo, l’exploit è estremamente semplice. Un attaccante può visitare un sito web, recuperare dal codice sorgente una API key utilizzata per servizi come Maps e inviarla a un endpoint Gemini. In diversi casi analizzati, la richiesta non restituisce un errore ma una risposta valida, segno che la chiave è accettata per operazioni sensibili.

Una volta ottenuto l’accesso, il threat actor può interrogare endpoint che contengono file caricati, dataset, documenti e contenuti cache del progetto. Oltre alla compromissione della riservatezza dei dati, emerge il rischio economico: l’uso massivo delle API generative può generare costi elevati e saturare le quote disponibili, causando interruzioni ai servizi legittimi. L’attaccante non deve compromettere infrastrutture o credenziali interne, ma semplicemente sfruttare una chiave pubblica già esposta.

L’impatto reale: migliaia di chiavi vulnerabili online

Un’analisi condotta sul dataset Common Crawl di novembre 2025 ha individuato 2.863 API key Google attive potenzialmente sfruttabili attraverso questo vettore. Tra le organizzazioni coinvolte figurano istituzioni finanziarie, aziende di sicurezza e realtà globali del recruiting, a dimostrazione di quanto il problema non sia limitato a progetti marginali.

Particolarmente significativo è il fatto che anche Google stessa presentasse chiavi pubbliche esposte su siti di prodotto che, una volta testate, risultavano valide per interrogare endpoint Gemini. Durante un test, una chiave pubblicata da anni per finalità innocue ha restituito una risposta positiva alla richiesta di elenco modelli generativi disponibili, confermando la trasformazione silenziosa dei privilegi.

La disclosure e la risposta di Google

La vulnerabilità è stata segnalata a Google nel novembre 2025 attraverso il Vulnerability Disclosure Program. In una prima fase il comportamento è stato classificato come previsto, ma l’evidenza fornita — inclusi esempi interni a Google — ha portato a una riclassificazione come bug e a un aumento della severità. L’azienda ha quindi avviato un piano di mitigazione che include la rilevazione automatica delle chiavi esposte e la limitazione del loro accesso a Gemini.

A gennaio 2026 il problema è stato formalmente catalogato come privilege escalation limitata a un singolo servizio, mentre a febbraio risultava ancora in fase di remediation strutturale. Nonostante le difficoltà iniziali nel triage, Google ha riconosciuto il rischio e ha ampliato i meccanismi di protezione per i clienti potenzialmente esposti. Ad oggi, però, la soluzione completa è ancora mancante. Google ha indicato alcune direttrici di miglioramento, tra cui default più restrittivi per le nuove chiavi generate tramite AI Studio, blocco automatico delle chiavi individuate come compromesse e notifiche proattive ai proprietari dei progetti.

Condividi l'articolo