„Nieszkodliwe” klucze Google API zaczęły ujawniać dane Gemini. Co się stało i jak się zabezpieczyć? - Security Bez Tabu

„Nieszkodliwe” klucze Google API zaczęły ujawniać dane Gemini. Co się stało i jak się zabezpieczyć?

Wprowadzenie do problemu / definicja luki

Przez lata wiele zespołów traktowało Google API keys (np. do Maps) jako „pół-publiczne” identyfikatory, które i tak muszą być widoczne w kodzie klienta (np. w JavaScripcie na stronie). Problem polega na tym, że wraz z upowszechnieniem Gemini (Generative Language API) część takich kluczy zaczęła działać jak poświadczenia do usług AI, co zmienia ich profil ryzyka: z „nadużycie = rachunki / limity Maps” na „nadużycie = dostęp do zasobów i danych w kontekście Gemini + kosztowne wywołania LLM”.

W skrócie

  • Badacze znaleźli ~2,8–3 tys. publicznie wystawionych kluczy Google API, które mogą zostać użyte do uwierzytelnienia wobec Gemini API.
  • Mechanizm ma charakter „retroaktywnego” rozszerzenia uprawnień: klucz utworzony np. pod Maps, po włączeniu Gemini w tym samym projekcie, może uzyskać dostęp do endpointów Gemini bez wyraźnego ostrzeżenia.
  • Google przekazał, że wdrożył środki: m.in. blokowanie wyciekłych kluczy próbujących użyć Gemini oraz zmianę domyślnych ustawień dla nowych kluczy z AI Studio.

Kontekst / historia / powiązania

Według opisu sprawy, Truffle Security przeskanowało zrzut Common Crawl z listopada 2025 i zidentyfikowało 2 863 „żywe” klucze widoczne w publicznym kodzie stron.
BleepingComputer podaje, że problem urósł do „prawie 3 000” kluczy, w tym pochodzących z organizacji o wysokim profilu (a nawet przykładów z infrastruktury Google).

Chronologia z raportu medialnego:

  • zgłoszenie do Google: 21 listopada 2025,
  • klasyfikacja problemu przez Google jako „single-service privilege escalation”: 13 stycznia 2026.

Analiza techniczna / szczegóły luki

Jak działa „eskalacja” w praktyce

  1. Zespół tworzy klucz API do usługi typu Maps/YouTube/Firebase i umieszcza go w kodzie klienta (HTML/JS).
  2. Ktoś w organizacji włącza Gemini API (Generative Language API) w tym samym projekcie Google Cloud.
  3. Ten sam klucz — często domyślnie unrestricted — może stać się ważnym poświadczeniem do endpointów Gemini, mimo że pierwotnie był traktowany jako mało wrażliwy.

Truffle Security opisuje to jako efekt niebezpiecznych domyślnych ustawień (klucze „unrestricted” i szerokie obowiązywanie na wszystkie włączone API w projekcie) oraz brak sygnału, że „pod spodem” zmienił się zakres uprawnień klucza.

Co dokładnie mogli testować badacze

W przytoczonym przykładzie badacze mieli wykonać połączenie do endpointu Gemini /models w celu listowania dostępnych modeli przy użyciu przejętego klucza. To dowodzi, że klucz „z weba” potrafił uwierzytelnić się do Gemini API.

Co mówi dokumentacja Google (ważne dla oceny ryzyka)

  • Google AI for Developers wprost podkreśla: nie wystawiaj kluczy po stronie klienta (web/mobile) w produkcji, bo da się je wyciągnąć; zaleca ograniczenia (IP/referrer/app) i ograniczanie zakresu API.
  • Google Cloud Documentation przypomina, że API keys są „unrestricted” domyślnie, a w produkcji należy ustawiać application restrictions i API restrictions.

Praktyczne konsekwencje / ryzyko

1) Dostęp do Gemini w kontekście Twojego projektu

Jeżeli w projekcie są zasoby lub funkcje powiązane z użyciem Gemini (np. pliki przesyłane w aplikacjach, cache, dane kontekstowe — zależnie od implementacji), przejęty klucz może dać atakującemu „wejście” do ścieżek API, do których klucz nigdy nie miał mieć dostępu.

2) Kosztowe nadużycia (AI bill abuse)

To może być też klasyczny wektor financial DoS: atakujący automatyzuje kosztowne wywołania modeli i generuje nieoczekiwane rachunki. Truffle Security ostrzega o ryzyku rachunków idących w tysiące dolarów dziennie w zależności od modelu i okna kontekstowego.

3) Trudność wykrycia

Najgorsze w tym scenariuszu jest to, że „wyciek” mógł mieć miejsce lata temu (bo klucz był jawnie w kodzie), a dopiero później stał się realnie niebezpieczny.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista w stylu „zrób dziś” (kolejność ma znaczenie):

  1. Sprawdź, czy Gemini/Generative Language API jest włączone w Twoich projektach (szczególnie tych „webowych”, gdzie historycznie trzymałeś Maps/YouTube keys).
  2. Zidentyfikuj klucze wystawione publicznie:
    • przeszukaj repozytoria, artefakty buildów, front-end bundle, strony WWW, CDN, dokumentację;
    • użyj narzędzi do skanowania sekretów (BleepingComputer wskazuje m.in. TruffleHog).
  3. Rotuj klucze natychmiast, jeśli mogły wyciec (publiczny JS/HTML = wyciek z definicji).
  4. Włącz restrykcje dla kluczy:
    • API restrictions: zezwól tylko na konkretne API potrzebne danej aplikacji,
    • Application restrictions: referrery dla WWW, IP dla backendów, podpisane aplikacje dla mobile.
  5. Rozdziel projekty (segregacja blast radius): osobny projekt dla prototypów AI, osobny dla „publicznych” integracji typu Maps. To minimalizuje efekt „włączenie nowego API → stary klucz nagle zyskuje nowe moce”. (To wprost wynika z opisanego mechanizmu eskalacji.)
  6. Przenieś wywołania Gemini na serwer (lub używaj mechanizmów tymczasowych tokenów tam, gdzie pasuje): Google zaleca serwer-side jako bezpieczniejszy wzorzec użycia klucza.
  7. Monitoring i alerty: ustaw detekcję anomalii użycia API i budżety/limity — dokumentacja Google podkreśla monitoring i logging jako praktykę ograniczającą skutki kompromitacji.

Różnice / porównania z innymi przypadkami

  • Klasyczny wyciek klucza API: „ktoś wrzucił sekret do repo”.
  • Ten przypadek: „sekret” był historycznie traktowany jako nie-sekret (bo w kliencie), ale stał się wrażliwy po zmianie powierzchni ataku (Gemini) i domyślnej polityce kluczy/projektów. To bardziej przypomina zmianę modelu zaufania niż pojedynczą wpadkę developera.

Podsumowanie / kluczowe wnioski

Jeśli w Twojej organizacji istnieją stare klucze Google API osadzone w kodzie stron lub aplikacji, to w świecie Gemini mogą one działać jak realne poświadczenia do usług AI. Najważniejsze działania to: audyt włączonych API, restrykcje kluczy (API + aplikacja), rotacja, rozdział projektów i przeniesienie wywołań Gemini na serwer. Google deklaruje dodatkowe zabezpieczenia (blokowanie wyciekłych kluczy dla Gemini i zmiany domyślnych ustawień), ale to nie zastępuje higieny kluczy po stronie użytkownika.

Źródła / bibliografia

  1. BleepingComputer — Previously harmless Google API keys now expose Gemini AI data (26 lutego 2026). (BleepingComputer)
  2. Truffle Security — Google API Keys Weren’t Secrets. But then Gemini Changed the Rules. (trufflesecurity.com)
  3. Google AI for Developers — Using Gemini API keys (sekcja zasad bezpieczeństwa). (Google AI for Developers)
  4. Google Cloud Documentation — Manage API keys / Apply API key restrictions (klucze „unrestricted” domyślnie, typy restrykcji). (Google Cloud Documentation)
  5. Google Cloud Documentation — Best practices for managing API keys (rotacja, brak kluczy w kodzie klienta, monitoring). (Google Cloud Documentation)