Google hat Entwicklern über mehr als ein Jahrzehnt hinweg klargemacht, dass API-Schlüssel – wie sie für Dienste wie Google Maps oder Firebase verwendet werden – keine Geheimnisse sind und sicher in Client-Code eingebettet werden dürfen. Doch mit der Einführung von Gemini hat sich dies grundlegend geändert: Die gleichen Schlüssel, die einst nur zur Projektidentifikation und Abrechnung dienten, können nun als authentifizierende Zugriffsrechte für sensible Daten in der KI-Plattform genutzt werden. Truffle Security hat Millionen von Webseiten analysiert und dabei fast 3.000 Google-API-Schlüssel entdeckt, die ursprünglich für öffentliche Dienste wie Maps verwendet wurden, aber nun uneingeschränkten Zugriff auf Gemini ermöglichen – ohne dass Entwickler je gewarnt wurden. Ein Angreifer, der einen solchen Schlüssel aus der Quelltextdatei einer Webseite extrahiert, kann nun auf hochsensible Daten wie hochgeladene Dateien, zwischengespeicherte Inhalte und sogar die Abrechnung für KI-Verarbeitung zugreifen. Selbst Google selbst hatte alte, öffentlich zugängliche Schlüssel, die wir zur Authentifizierung im internen Gemini-System nutzen konnten. Der Kern des Problems liegt in der einheitlichen Schlüsselarchitektur von Google Cloud: Ein und derselbe Schlüsseltyp (AIza...) wird für zwei völlig unterschiedliche Zwecke verwendet – als öffentlicher Projekt-Identifikator und als sensibler Authentifizierungsschlüssel. Während Google jahrelang betont hat, dass API-Schlüssel keine Geheimnisse seien und in HTML oder JavaScript sicher sein würden, hat die Aktivierung des Generative Language API (Gemini) diese Annahme zerstört. Sobald die API aktiviert ist, erhalten bereits bestehende, öffentlich zugängliche Schlüssel automatisch Zugriff auf sensible Endpunkte – ohne Warnung, ohne Bestätigung, ohne Benachrichtigung. Dies führt zu einer retroaktiven Privileg-Erweiterung: Ein Schlüssel, der ursprünglich harmlos war, wird plötzlich zu einem potenten Zugriffsschlüssel. Zudem ist der Standard für neue Schlüssel „Unrestricted“, was bedeutet, dass sie sofort auf alle APIs in einem Projekt zugreifen können – inklusive Gemini. Dies stellt eine Insecure Default-Implementierung (CWE-1188) und eine falsche Berechtigungsvergabe (CWE-269) dar. Die Auswirkungen sind gravierend: Ein Angreifer braucht nur eine Webseite zu besuchen, den Schlüssel aus dem Quellcode zu kopieren und ihn direkt in API-Anfragen einzusetzen. Statt einer 403-Fehlermeldung erhält er eine 200-OK-Antwort. Damit kann er Quoten erschöpfen, Dienste lahmlegen oder die Abrechnung für KI-Nutzung auf das eigene Konto legen. Die Analyse des Common Crawl-Datensatzes aus November 2025 ergab 2.863 aktive, öffentlich zugängliche Schlüssel, darunter auch solche von Finanzinstituten, Sicherheitsfirmen und Google selbst. Die Entdeckung wurde am 21. November 2025 bei Google gemeldet. Zunächst wurde die Meldung als „intendiertes Verhalten“ abgelehnt, doch nach Nachweis mit Schlüsseln aus Google-Produkten wurde das Problem als kritischer Bug klassifiziert und am 13. Januar 2026 als „Single-Service Privilege Escalation, READ“ (Tier 1) eingestuft. Google hat seitdem Maßnahmen ergriffen, darunter eine Erweiterung ihrer Erkennungssysteme für verlorene Schlüssel und die Einschränkung des Zugriffs auf betroffene Schlüssel. Industrieexperten sehen in diesem Vorfall ein typisches Beispiel für die Herausforderungen bei der Integration von KI in bestehende Systeme: Legacy-Infrastruktur wird mit neuen, sensiblen Funktionen belastet, ohne dass die Sicherheitsannahmen aktualisiert werden. Google hat bereits Verbesserungen angekündigt, doch bleibt offen, ob sie bestehende Schlüssel retroaktiv prüfen und Kunden informieren werden. Für alle Nutzer von Google Cloud ist es dringend ratsam, alle Projekte auf aktiviertes Generative Language API zu prüfen, die zugehörigen Schlüssel auf öffentliche Exposition zu überprüfen und gegebenenfalls zu rotieren. Tools wie TruffleHog können helfen, aktive, gefährdete Schlüssel zu identifizieren. Die Lektion ist klar: Was einst als sicher galt, kann heute eine kritische Sicherheitslücke sein – besonders, wenn sich die Funktionen von APIs ändern, ohne dass die zugrundeliegende Sicherheitsarchitektur angepasst wird.