Google API keys कभी secret नहीं थे। लेकिन Gemini ने नियम बदल दिए

• Google 10 साल से भी ज़्यादा समय से यह बताता रहा कि API keys secret नहीं हैं और उन्हें public करना सुरक्षित है, लेकिन Gemini API enabled होने के बाद वही keys एक sensitive authentication mechanism में बदल गईं
• पहले Google Maps, Firebase आदि में इस्तेमाल होने वाली public keys को अपने-आप Gemini API access permission मिल गई, जिससे public keys के ज़रिए personal data access करना और charges लगाना संभव हो गया
• Truffle Security ने पुष्टि की कि 2,863 production Google API keys इंटरनेट पर exposed हैं, जिनमें से कुछ Google की अपनी services की keys भी शामिल हैं
• Google ने समस्या स्वीकार की है और leaked key blocking, Gemini-only defaults, और exposure notification features ला रहा है, लेकिन मौजूदा keys की retrospective review अभी पूरी नहीं हुई है
• यह मामला दिखाता है कि AI feature integration की वजह से existing credentials के permissions बढ़ने का risk कितना गंभीर हो सकता है, और developers को तुरंत Gemini API enablement और key exposure status की जांच करनी चाहिए

---

मुख्य समस्या

• Google Cloud AIza... फ़ॉर्मैट की single API key structure का उपयोग करता है, जो public identification और sensitive authentication दोनों उद्देश्यों को एक साथ पूरा करती है
  • पहले Google ने developers को साफ़ तौर पर बताया था कि API keys को client code में सीधे शामिल करना सुरक्षित है
  • Firebase security checklist में भी कहा गया था कि “API keys secret नहीं हैं”
• लेकिन जैसे ही Gemini API enabled होती है, मौजूदा project की सभी API keys को अपने-आप Gemini endpoints तक access permission मिल जाती है
  • permission expansion बिना warning, confirmation process, या email notification के होती है
• इससे दो समस्याएँ पैदा होती हैं
  • Retroactive Privilege Expansion: पहले public रही Maps key अब Gemini access credential बन जाती है
  • Insecure Defaults: नई key बनाते समय default setting “Unrestricted” रहती है, जिससे Gemini सहित सभी APIs तक access संभव होता है
• नतीजतन, हज़ारों billing tokens असली authentication credentials में बदलकर इंटरनेट पर exposed हो गए हैं

संभावित attack scenario

• attacker किसी website के source code से AIza... key कॉपी करके एक साधारण curl request से Gemini API तक पहुँच सकता है
  • उदाहरण: curl "https://generativelanguage.googleapis.com/v1beta/files/…;
  • अगर valid response (200 OK) मिलता है, तो uploaded files, cached data जैसी sensitive information तक access संभव हो जाता है
• इसके ज़रिए attacker
  • private data access कर सकता है (/files/, /cachedContents/ endpoints)
  • Gemini API usage charges पीड़ित पर डाल सकता है
  • quota exhaust करके service disruption पैदा कर सकता है
• attacker को victim infrastructure में घुसने की ज़रूरत नहीं होती; सिर्फ public web pages से key निकालकर हमला किया जा सकता है

exposed keys का पैमाना

• Truffle Security ने Common Crawl November 2025 dataset (लगभग 700TiB) का विश्लेषण करके 2,863 active Google API keys खोजीं
  • ये keys मूल रूप से Google Maps जैसी public services के लिए इस्तेमाल हो रही थीं, लेकिन इनके पास Gemini API access permission भी थी
• प्रभावित targets में financial institutions, security companies, global recruiting firms, और खुद Google शामिल थे
  • यानी Google भी उसी structural risk के संपर्क में था

Google internal key case

• Truffle Security ने Google product website के public source code में शामिल key से Gemini API access का प्रदर्शन किया
  • वह key February 2023 से पहले से public थी, और मूल रूप से सिर्फ project identification के लिए इस्तेमाल की गई थी
  • /models endpoint call करने पर valid response (200 OK) मिला, जिससे sensitive API access संभव होना साबित हुआ
• यानी पहले harmless रही key ने बिना developer intervention के sensitive privileges हासिल कर लिए

vulnerability report और response timeline

• 21 November 2025: Google VDP को report किया गया
• 25 November: Google ने इसे “intended behavior” माना
• 1–2 December: Truffle Security ने Google internal key case दिखाया, जिसके बाद Google ने इसे bug के रूप में reclassify किया और severity बढ़ाई
• 12 December: Google ने leaked key detection pipeline expansion और Gemini access restriction measures शुरू किए
• 13 January 2026: Google ने vulnerability को “Single-Service Privilege Escalation (READ)” के रूप में classify किया
• 2 February: पुष्टि हुई कि root-cause fix पर काम चल रहा है

Google के follow-up measures

• Google ने official docs में निम्न security hardening plans घोषित किए
  • Scoped defaults: AI Studio में बनाई गई नई keys में सिर्फ Gemini-specific access की अनुमति होगी
  • Leaked key blocking: leaked keys के Gemini API access को अपने-आप block किया जाएगा
  • Proactive notification: leaked key detect होते ही users को तुरंत alert भेजा जाएगा
• कुछ सुधार पहले से लागू हो रहे हैं, लेकिन मौजूदा exposed keys की retrospective review और user notification अभी पूरी नहीं हुई है

developer check guide

• Step 1: सभी GCP projects में Generative Language API enabled है या नहीं, यह जाँचें
• Step 2: अगर enabled है, तो API key settings में ‘Unrestricted’ या Gemini शामिल करने वाली keys पहचानें
• Step 3: जाँचें कि क्या वह key public code या web page में शामिल है
  • exposed key को तुरंत rotate करना चाहिए
• Bonus: TruffleHog tool का उपयोग करके Gemini access वाली real-world keys का automatic detection किया जा सकता है
  • command example: trufflehog filesystem /path/to/your/code --only-verified

निष्कर्ष

• यह मामला दिखाता है कि AI features जुड़ने पर पहले public credentials को sensitive privileges मिल जाने का structural risk कितना गंभीर हो सकता है
• Google समस्या को पहचान चुका है और response दे रहा है, लेकिन safe defaults और key separation design की अहमियत फिर से सामने आई है
• developers और companies को Gemini API enablement और key exposure status की तुरंत जाँच करनी चाहिए