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 की तुरंत जाँच करनी चाहिए

[GN⁺]

Hacker News की राय

• Google AI Studio के दस्तावेज़ open proxy के ज़रिए ऐप deploy करने की सिफारिश कर रहे हैं
  यह तरीका यह गलत धारणा देता है कि API key proxy के पीछे है, इसलिए सुरक्षित है, लेकिन वास्तव में इससे AI billing abuse संभव हो जाता है
  जिन ऐप्स में AI feature बिल्कुल नहीं है, वे भी अगर key scope को manually सीमित न किया गया हो तो महंगे models के संपर्क में आ जाते हैं
  ऐसे कमजोर ऐप्स Google, Twitter, Hacker News search भर से आसानी से मिल सकते हैं
  संबंधित विश्लेषण इस लेख में संकलित है

• Google कहता है कि वह leaked keys को block कर रहा है, लेकिन शुरू से ही उन keys को secret की तरह माना ही नहीं गया था
  आदर्श रूप से Gemini लॉन्च से पहले बनाई गई सभी keys को Gemini तक पहुँच से रोक देना चाहिए था
  अगर leak detection system false positive देता है, तो सामान्य Gemini keys भी block होने का जोखिम है

  • यह समस्या इतनी साधारण नहीं है कि सिर्फ block करके सुलझ जाए
    कम से कम Generative Language API permission सभी मौजूदा keys से हटानी चाहिए, लेकिन वह भी पूरा समाधान नहीं है
    अंततः सभी keys से यह permission सामूहिक रूप से हटानी पड़ सकती है
    इससे अनगिनत applications टूट जाएँगी, और यही वजह है कि Google शायद इस समस्या को मानना नहीं चाहता
    इससे भी गंभीर बात यह है कि keys से cached context और uploaded data तक भी expose हो जाते हैं

• पता चला कि पुराने Android images में hardcoded Google keys वास्तव में Gemini के साथ इस्तेमाल किए जा सकते थे
  कुछ पर पहले से बहुत लोग इस्तेमाल कर रहे थे, इसलिए rate limit लग चुकी थी, लेकिन कुछ अभी भी काम कर रहे थे
  लगभग दो महीने पहले इन keys को leaked माना गया और सबको disable कर दिया गया

• बहुत पहले बनाई गई keys मूल रूप से Firebase या Firestore जैसी सीमित services के लिए थीं
  लेकिन Gemini लॉन्च के बाद, मौजूदा keys पर भी Gemini access अपने-आप enable हो गया, जिससे abuse आसान हो गया
  यानी APK file में शामिल public key सीधे Gemini access key बन गई

  • Gemini API डिफ़ॉल्ट रूप से disable रहता है, लेकिन project स्तर पर enable होते ही समस्या पैदा होती है
    उदाहरण के लिए, developer X ने Maps के लिए key बनाई और उसी project में developer Y ने Gemini चालू कर दिया, तो
    X की key को Gemini access permission मिल जाती है
    इसलिए project reuse से बचना चाहिए, और हर service के लिए अलग GCP project इस्तेमाल करना चाहिए

• सवाल यह है कि इतनी स्पष्ट security flaw पहले क्यों नहीं पकड़ी गई
  Google जैसी बड़ी कंपनी में standardized testing या spec तो होना ही चाहिए

  • Google अब पहले वाला Google नहीं रहा
    संगठन जितना बड़ा और जटिल होता जाता है, ऐसे oversight blind spots उतने ही बढ़ते हैं
  • ऐसी बुनियादी security validation को interview item बनाने का सुझाव भी था,
    लेकिन वे अब भी सिर्फ binary tree invert करने वाले सवालों में उलझे रहे
  • Google की असली expertise ads बेचने में है
  • Security अब भी developers के लिए सबसे कम ध्यान दिया जाने वाला last frontier है
  • विशाल संगठनों में अक्सर एक हाथ को दूसरे हाथ के काम का पता नहीं होता

• यह मामला पुराने SSN (Social Security Number) misuse की याद दिलाता है
  वह मूल रूप से सिर्फ identification number था, लेकिन एक समय बाद authentication key की तरह इस्तेमाल होने लगा और समस्या बढ़ती गई
  जल्दी और सस्ता implement करने की कोशिश अंत में लागत को users पर डाल देती है

• ऐसा लगता है कि Google अभी तक इस समस्या को पूरी तरह सुलझा नहीं पाया है
  Gemini को जल्दी लॉन्च करने की वजह से हुई यह बड़ी गलती है,
  और इसे ठीक करने के लिए पुरानी keys को disable करना पड़े तो customer workflows बुरी तरह टूट सकते हैं
  Google के लिए भी यह बहुत गंभीर image damage है

• यह एक तरह की retroactive privilege expansion समस्या है
  आपने पुरानी Maps key वेबसाइट पर public रखी थी, लेकिन टीम के किसी दूसरे developer ने Gemini चालू किया, तो
  वही public key तुरंत Gemini access credential बन जाती है
  नतीजतन कोई भी उस key से file uploads या cached data तक पहुँच सकता है

  • नई features को मौजूदा keys पर नहीं, बल्कि सिर्फ explicitly opt-in की गई नई keys पर लागू करना चाहिए था
    पुराने दस्तावेज़ों के अनुसार public keys इस्तेमाल करने वाले users इसका नुकसान उठा रहे हैं
  • बेशक Maps key को public रखना मूल रूप से भी जोखिम भरा है
    हमलावर उस key को चुराकर billing blast कर सकता है

• आसान भाषा में कहें तो, हज़ारों मौजूदा API keys साधारण billing token से
  अचानक Gemini access credential में बदल गईं
  Maps API key मूल रूप से इस तरह बनाई गई थी कि users को map service मिले और भुगतान मेरे card से हो
  समस्या यह है कि अब यही keys Gemini तक भी पहुँच सकती हैं
  internal-use project अलग बनाकर keys को अलग रखना चाहिए था,
  लेकिन जल्दी deploy करने के चक्कर में LLM-generated code को ज्यों का त्यों इस्तेमाल किया गया, और समस्या आने पर दोष Google पर डाला गया

  • लेकिन असली समस्या यह है कि Maps key अब Gemini के sensitive content तक भी पहुँच सकती है

• इस समस्या का विश्लेषण करने वाली security company का पिछला research भी प्रभावशाली था
  उदाहरण के लिए “Anyone can Access Deleted and Private Repository Data on GitHub” जैसे लेख में
  deleted GitHub repository data access vulnerability को उजागर किया गया था
  इस बार भी उनका विश्लेषण बहुत मददगार रहा