Google API Keys: le chiavi pubbliche diventano credenziali sensibili
好,我现在需要帮用户总结这篇文章的内容,控制在100个字以内。首先,我得仔细阅读文章,抓住主要信息。 文章讲的是Google Cloud引入Gemini后,API key的安全问题。传统上,API key只是作为项目标识符,不需要保密。但Gemini的到来让这些key获得了新的权限,可以访问敏感的生成模型和数据。这导致了很多潜在的安全风险。 接下来,文章提到很多API key被公开暴露在代码中,攻击者可以轻易获取并利用这些key来访问敏感数据或产生高额费用。研究者发现了数千个这样的key,并且甚至Google自己的网站也有暴露的情况。 最后,Google虽然采取了一些措施来缓解问题,比如自动检测和限制访问,但整体解决方案还在进行中。 总结的时候要注意控制字数,突出关键点:Gemini引入导致API key权限扩大、大量key暴露、安全风险以及Google的应对措施。 </think> Google Cloud引入生成式AI功能后,传统API密钥获得新权限,导致大量密钥暴露风险。攻击者可利用这些密钥访问敏感数据并引发经济风险。研究发现数千个密钥受影响,Google已采取部分缓解措施。 2026-2-27 08:15:29 Author: www.securityinfo.it(查看原文) 阅读量:4 收藏

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


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.



Altro in questa categoria


文章来源: https://www.securityinfo.it/2026/02/27/google-api-keys-le-chiavi-pubbliche-diventano-credenziali-sensibili/
如有侵权请联系:admin#unsafe.sh