Google API Key ไม่ได้เป็นความลับ แต่ Gemini เปลี่ยนกติกา

 (trufflesecurity.com)
5 คะแนน โดย GN⁺ 2026-02-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google แนะนำมานานกว่า 10 ปีว่า API key ไม่ใช่ความลับและเปิดเผยได้อย่างปลอดภัย แต่หลังจาก เปิดใช้ Gemini API คีย์เดียวกันกลับกลายเป็นวิธีการยืนยันตัวตนที่มีความอ่อนไหว
  • คีย์สาธารณะที่ใช้กับ Google Maps, Firebase ฯลฯ เดิม ได้สิทธิ์เข้าถึง Gemini API โดยอัตโนมัติ ทำให้ คีย์ที่เปิดเผยสามารถเข้าถึงข้อมูลส่วนตัวและก่อให้เกิดการเรียกเก็บเงินได้
  • Truffle Security ยืนยันว่ามี Google API key ที่ใช้งานจริง 2,863 รายการ ถูกเปิดเผยบนอินเทอร์เน็ต และบางส่วนเป็น คีย์ของบริการของ Google เอง
  • Google ยอมรับปัญหาและกำลังนำ การบล็อกคีย์ที่รั่วไหล, ค่าเริ่มต้นเฉพาะสำหรับ Gemini, และฟังก์ชันแจ้งเตือนเมื่อพบการเปิดเผย มาใช้ แต่ การตรวจสอบย้อนหลังสำหรับคีย์เดิมยังไม่เสร็จสมบูรณ์
  • กรณีนี้แสดงให้เห็นถึง ความเสี่ยงจากการขยายสิทธิ์ของข้อมูลรับรองเดิมเมื่อผนวกรวมความสามารถ AI และนักพัฒนาจำเป็นต้องตรวจสอบทันทีว่า มีการเปิดใช้ Gemini API และมีการเปิดเผยคีย์หรือไม่

ปัญหาหลัก

  • Google Cloud ใช้โครงสร้าง API key แบบเดี่ยว ในรูปแบบ AIza... ซึ่งทำหน้าที่พร้อมกันสองอย่าง คือ ใช้ระบุตัวตนแบบสาธารณะ และ ใช้ยืนยันตัวตนแบบอ่อนไหว
    • ในอดีต Google ระบุชัดเจนกับนักพัฒนาว่า API key ปลอดภัยแม้ฝังไว้ในโค้ดฝั่งไคลเอนต์โดยตรง
    • ในเช็กลิสต์ความปลอดภัยของ Firebase ก็ระบุว่า “API key ไม่ใช่ความลับ”
  • แต่เมื่อเปิดใช้ Gemini API แล้ว API key ทุกตัวของโปรเจกต์เดิมจะได้รับสิทธิ์เข้าถึง endpoint ของ Gemini โดยอัตโนมัติ
    • สิทธิ์ถูกขยาย โดยไม่มีคำเตือน ขั้นตอนยืนยัน หรืออีเมลแจ้งเตือน
  • สิ่งนี้ทำให้เกิดปัญหาสองด้าน
    • การขยายสิทธิ์ย้อนหลัง (Retroactive Privilege Expansion): คีย์ Maps ที่เคยเปิดเผยในอดีต กลายเป็นข้อมูลรับรองสำหรับเข้าถึง Gemini
    • ค่าเริ่มต้นที่ไม่ปลอดภัย (Insecure Defaults): เมื่อสร้างคีย์ใหม่ การตั้งค่าเริ่มต้นเป็น “Unrestricted” ทำให้เข้าถึงได้ทุก API รวมถึง Gemini
  • ผลลัพธ์คือ โทเคนสำหรับการเรียกเก็บเงินหลายพันรายการได้กลายเป็นข้อมูลรับรองสำหรับยืนยันตัวตนจริง และถูกเปิดเผยอยู่บนอินเทอร์เน็ต

สถานการณ์การโจมตีที่เป็นไปได้

  • ผู้โจมตีสามารถคัดลอกคีย์ AIza... จากซอร์สโค้ดของเว็บไซต์ แล้วเข้าถึง Gemini API ได้ด้วย คำขอ curl แบบง่าย ๆ
    • ตัวอย่าง: curl "https://generativelanguage.googleapis.com/v1beta/files/…;
    • หากได้รับการตอบกลับปกติ (200 OK) ก็อาจ เข้าถึงข้อมูลอ่อนไหว เช่น ไฟล์ที่อัปโหลดหรือข้อมูลแคชได้
  • ผู้โจมตีสามารถใช้สิ่งนี้เพื่อ
    • เข้าถึงข้อมูลที่ไม่เปิดเผย (/files/, /cachedContents/ endpoints)
    • สร้างค่าใช้จ่ายจากการใช้งาน Gemini API
    • ทำให้บริการหยุดชะงักจากการใช้โควตาจนหมด
  • ผู้โจมตีไม่จำเป็นต้องเจาะโครงสร้างพื้นฐานของเหยื่อ เพียงแค่ ดึงคีย์จากหน้าเว็บสาธารณะ ก็สามารถโจมตีได้

ขนาดของคีย์ที่ถูกเปิดเผย

  • Truffle Security วิเคราะห์ ชุดข้อมูล Common Crawl เดือนพฤศจิกายน 2025 (ประมาณ 700TiB) และพบ Google API key ที่ยังใช้งานได้ 2,863 รายการ
    • คีย์เหล่านี้เดิมใช้กับ บริการสาธารณะอย่าง Google Maps แต่มีสิทธิ์เข้าถึง Gemini API ด้วย
  • กลุ่มที่ได้รับผลกระทบมีทั้ง สถาบันการเงิน บริษัทด้านความปลอดภัย บริษัทจัดหางานระดับโลก และแม้แต่ Google เอง
    • แสดงให้เห็นว่า Google เองก็เผชิญความเสี่ยงเชิงโครงสร้างแบบเดียวกัน

กรณีคีย์ภายในของ Google

  • Truffle Security สาธิตการเข้าถึง Gemini API โดยใช้ คีย์ที่รวมอยู่ในซอร์สโค้ดสาธารณะของเว็บไซต์ผลิตภัณฑ์ Google
    • คีย์ดังกล่าว ถูกเปิดเผยต่อสาธารณะมาตั้งแต่ก่อนเดือนกุมภาพันธ์ 2023 และเดิมใช้เพียงเพื่อระบุโปรเจกต์เท่านั้น
    • เมื่อเรียก /models endpoint ก็ได้รับ การตอบกลับปกติ (200 OK) ยืนยันว่า สามารถเข้าถึง API ที่อ่อนไหวได้
  • นั่นหมายความว่า คีย์ที่เคยไม่เป็นอันตรายในอดีตได้รับสิทธิ์ที่อ่อนไหวโดยที่นักพัฒนาไม่ได้เข้ามาเกี่ยวข้อง

ไทม์ไลน์การรายงานช่องโหว่และการตอบสนอง

  • 21 พฤศจิกายน 2025: รายงานไปยัง Google VDP
  • 25 พฤศจิกายน: Google พิจารณาว่าเป็น “พฤติกรรมที่ตั้งใจไว้”
  • 1–2 ธันวาคม: หลัง Truffle Security นำเสนอกรณีคีย์ภายในของ Google ทาง Google จึง จัดประเภทใหม่ว่าเป็นบั๊กและยกระดับความร้ายแรง
  • 12 ธันวาคม: Google เริ่ม ขยาย pipeline สำหรับตรวจจับคีย์ที่รั่วไหลและจำกัดการเข้าถึง Gemini
  • 13 มกราคม 2026: Google จัดประเภทช่องโหว่นี้เป็น “การยกระดับสิทธิ์ภายในบริการเดียว (Single-Service Privilege Escalation, READ)”
  • 2 กุมภาพันธ์: ยืนยันว่ากำลังดำเนินการแก้ไขที่ต้นตอของปัญหา

มาตรการติดตามของ Google

  • Google ประกาศ แผนเสริมความปลอดภัย ต่อไปนี้ในเอกสารทางการ
    • Scoped defaults: คีย์ใหม่ที่สร้างใน AI Studio จะ อนุญาตให้เข้าถึงเฉพาะ Gemini เท่านั้น
    • Leaked key blocking: บล็อกการเข้าถึง Gemini API ของคีย์ที่รั่วไหลโดยอัตโนมัติ
    • Proactive notification: แจ้งเตือนผู้ใช้ทันทีเมื่อพบคีย์ที่ถูกเปิดเผย
  • แม้บางส่วนเริ่มดำเนินการแล้ว แต่ การตรวจสอบย้อนหลังของคีย์ที่เปิดเผยไปก่อนหน้าและการแจ้งผู้ใช้ยังไม่เสร็จสมบูรณ์

แนวทางตรวจสอบสำหรับนักพัฒนา

  • ขั้นตอนที่ 1: ตรวจสอบทุกโปรเจกต์ GCP ว่า มีการเปิดใช้ Generative Language API หรือไม่
  • ขั้นตอนที่ 2: หากเปิดใช้แล้ว ให้ตรวจสอบการตั้งค่า API key เพื่อหา คีย์ที่เป็น ‘Unrestricted’ หรือรวม Gemini ไว้
  • ขั้นตอนที่ 3: ตรวจสอบว่า คีย์ดังกล่าวอยู่ในโค้ดสาธารณะหรือหน้าเว็บหรือไม่
    • หากคีย์ถูกเปิดเผย ต้อง หมุนคีย์ (rotating) ทันที
  • เพิ่มเติม: สามารถใช้เครื่องมือ TruffleHog เพื่อ ตรวจจับคีย์ที่ใช้งานจริงและเข้าถึง Gemini ได้โดยอัตโนมัติ
    • ตัวอย่างคำสั่ง: trufflehog filesystem /path/to/your/code --only-verified

บทสรุป

  • กรณีนี้แสดงให้เห็นถึง ความเสี่ยงเชิงโครงสร้างที่ข้อมูลรับรองสาธารณะเดิมได้รับสิทธิ์อ่อนไหวจากการเพิ่มความสามารถ AI
  • แม้ Google จะรับรู้ปัญหาและกำลังตอบสนอง แต่ ความสำคัญของค่าเริ่มต้นที่ปลอดภัยและการออกแบบแยกคีย์ ก็ถูกเน้นย้ำอีกครั้ง
  • นักพัฒนาและองค์กรควร ตรวจสอบการเปิดใช้ Gemini API และสถานะการเปิดเผยคีย์โดยทันที

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-26
ความเห็นจาก Hacker News

  • เอกสารของ Google AI Studio แนะนำให้เผยแพร่แอปผ่าน open proxy
    วิธีนี้ทำให้คนเข้าใจผิดว่า API key ปลอดภัยเพราะอยู่หลังพร็อกซี แต่ความจริงแล้วเปิดทางให้เกิด การใช้ AI แบบกินค่าใช้จ่ายโดยมิชอบ
    แม้แต่แอปที่ไม่มีฟีเจอร์ AI เลย หากไม่ได้จำกัดขอบเขตของคีย์ด้วยตนเอง ก็ยังอาจเข้าถึงโมเดลราคาแพงได้
    แอปที่เปราะบางลักษณะนี้ยังค้นหาเจอได้ง่ายเพียงแค่ใช้ Google, Twitter หรือค้นหาใน Hacker News
    การวิเคราะห์ที่เกี่ยวข้องสรุปไว้ในบทความนี้

  • แม้ Google จะบอกว่าจะบล็อกคีย์ที่รั่วไหล แต่ตั้งแต่แรกพวกเขาก็ ไม่ได้ปฏิบัติต่อคีย์เหล่านั้นว่าเป็นความลับ
    ทางที่เหมาะที่สุดคือควรป้องกันไม่ให้คีย์ทั้งหมดที่สร้างก่อนการเปิดตัว Gemini เข้าถึง Gemini ได้
    หากระบบตรวจจับการรั่วไหลมี false positive ก็เสี่ยงที่จะบล็อกแม้แต่ Gemini key ที่ใช้งานปกติ

    • ปัญหานี้ไม่ใช่สิ่งที่แก้ได้ด้วยการบล็อกอย่างเดียว
      อย่างน้อยที่สุดควรถอด สิทธิ์ของ Generative Language API ออกจากคีย์เดิมทั้งหมด แต่ถึงอย่างนั้นก็ยังไม่ใช่คำตอบที่สมบูรณ์
      สุดท้ายอาจต้องถอดสิทธิ์ดังกล่าวออกจากทุกคีย์แบบครอบคลุม
      นั่นจะทำให้แอปจำนวนมหาศาลพัง และเป็นเหตุผลที่ Google ไม่อยากยอมรับปัญหานี้
      ที่ร้ายแรงกว่านั้นคือคีย์ยังเปิดให้เข้าถึง cached context และข้อมูลที่อัปโหลด ได้ด้วย

  • มีคนพบว่า Google key ที่ hardcode อยู่ในอิมเมจ Android รุ่นเก่า สามารถนำมาใช้กับ Gemini ได้จริง
    บางคีย์ถูกคนจำนวนมากใช้ไปแล้วจนโดน rate limit แต่บางคีย์ก็ยังใช้งานได้
    ราวสองเดือนก่อน คีย์เหล่านี้ถูกมองว่าเป็นคีย์ที่รั่วไหลและถูกปิดใช้งานทั้งหมด

  • คีย์ที่สร้างไว้นานแล้วเดิมทีตั้งใจให้ใช้กับบริการที่จำกัดอย่าง Firebase หรือ Firestore เท่านั้น
    แต่หลัง Gemini เปิดตัว การเข้าถึง Gemini กลับถูก เปิดใช้งานให้อัตโนมัติ กับคีย์เดิมด้วย ทำให้ถูกนำไปใช้ในทางที่ผิดได้ง่ายขึ้น
    เท่ากับว่า public key ที่ฝังอยู่ในไฟล์ APK กลายเป็นคีย์สำหรับเข้าถึง Gemini ไปโดยตรง

    • Gemini API ปกติจะปิดไว้เป็นค่าเริ่มต้น แต่เมื่อเปิดในระดับโปรเจกต์แล้วก็จะเกิดปัญหา
      ตัวอย่างเช่น หากนักพัฒนา X สร้างคีย์ไว้สำหรับ Maps แล้วนักพัฒนาอีกคน Y เปิด Gemini ในโปรเจกต์เดียวกัน
      คีย์ของ X ก็จะได้สิทธิ์เข้าถึง Gemini ไปด้วย
      ดังนั้นควร หลีกเลี่ยงการใช้โปรเจกต์ร่วมกันซ้ำ และใช้ GCP project แยกตามแต่ละบริการ

  • หลายคนสงสัยว่าทำไมข้อบกพร่องด้านความปลอดภัยที่ชัดเจนขนาดนี้ถึงไม่ถูกกรองออกตั้งแต่แรก
    ถ้าเป็นบริษัทใหญ่อย่าง Google ก็ควรมี การทดสอบหรือสเปกมาตรฐาน อยู่แล้ว

    • Google ไม่ใช่ Google แบบเดิมอีกต่อไป
      ยิ่งองค์กรใหญ่และซับซ้อนขึ้นเท่าไร จุดบอดในการกำกับดูแล ก็ยิ่งเพิ่มขึ้นเท่านั้น
    • เคยมีข้อเสนอให้เอาการตรวจสอบความปลอดภัยพื้นฐานแบบนี้ไปเป็นคำถามสัมภาษณ์ แต่
      พวกเขาก็ยังหมกมุ่นอยู่กับโจทย์ กลับด้าน binary tree เหมือนเดิม
    • ความเชี่ยวชาญที่แท้จริงของ Google คือ การขายโฆษณา
    • ความปลอดภัยยังคงเป็น ด่านสุดท้าย ที่นักพัฒนาให้ความสำคัญน้อยที่สุด
    • ในองค์กรขนาดใหญ่มักเกิดภาวะที่มือซ้ายไม่รู้ว่ามือขวากำลังทำอะไร

  • เหตุการณ์นี้ทำให้นึกถึงกรณีการนำ SSN (หมายเลขประกันสังคม) ไปใช้ผิดวัตถุประสงค์ในอดีต
    เดิมทีเป็นเพียงหมายเลขสำหรับระบุตัวตน แต่เมื่อถึงจุดหนึ่งกลับถูกใช้เป็นคีย์ยืนยันตัวตนจนปัญหาขยายใหญ่ขึ้น
    เป็นโครงสร้างแบบทำให้เสร็จเร็วและถูก แต่สุดท้ายผลักภาระต้นทุนไปให้ผู้ใช้

  • ดูเหมือนว่า Google ยัง แก้ปัญหานี้ไม่เสร็จสมบูรณ์
    มันเป็นความผิดพลาดครั้งใหญ่จากการเร่งเปิดตัว Gemini และ
    หากจะแก้จริงก็อาจต้องปิดคีย์เดิม ซึ่งมีโอกาสสูงที่จะทำให้ workflow ของลูกค้าพัง
    ในมุมของ Google เอง นี่ก็เป็น ความเสียหายต่อภาพลักษณ์อย่างรุนแรง

  • นี่เป็นปัญหาแบบ Retroactive Privilege Expansion อย่างหนึ่ง
    เดิมมีการเปิดเผย Maps key ไว้บนเว็บไซต์ แต่เมื่อมีนักพัฒนาอีกคนในทีมเปิด Gemini
    public key นั้นก็กลายเป็นข้อมูลรับรองสำหรับเข้าถึง Gemini ทันที
    ผลคือใครก็ตามสามารถใช้คีย์นั้นอัปโหลดไฟล์หรือเข้าถึงข้อมูลแคชได้

    • ฟีเจอร์ใหม่ควรถูกใช้กับ คีย์ใหม่ที่ opt-in อย่างชัดเจน เท่านั้น ไม่ใช่กับคีย์เดิม
      ผู้ใช้ที่ทำตามเอกสารเก่าและใช้ public key กำลังเป็นฝ่ายรับผลกระทบ
    • แน่นอนว่าการเปิดเผย Maps key เดิมทีก็มีความเสี่ยงอยู่แล้ว
      ผู้โจมตีสามารถขโมยคีย์นั้นไปก่อ บิลค่าใช้จ่ายพุ่ง ได้

  • ถ้าอธิบายให้ง่ายขึ้น ก็คือ API key เดิมนับพันรายการที่เคยเป็นแค่โทเคนสำหรับการคิดค่าบริการ
    จู่ ๆ ก็กลายเป็น ข้อมูลรับรองสำหรับเข้าถึง Gemini
    Maps API key เดิมถูกออกแบบมาเพื่อให้ผู้ใช้เรียกใช้บริการแผนที่ โดยให้บัตรของฉันเป็นคนจ่าย
    ปัญหาคือคีย์เหล่านี้ตอนนี้กลับใช้เข้าถึง Gemini ได้ด้วย
    เดิมควรแยกโปรเจกต์ภายในออกมาต่างหากเพื่อแยกคีย์ แต่
    พอเร่งปล่อยของก็ใช้ โค้ดที่ LLM สร้างให้ ตรง ๆ และพอมีปัญหาก็โทษ Google

    • แต่ปัญหาจริงคือ Maps key ตอนนี้สามารถเข้าถึง เนื้อหาที่ละเอียดอ่อน ของ Gemini ได้แล้ว

  • งานวิจัยก่อนหน้าของบริษัทรักษาความปลอดภัยที่วิเคราะห์ปัญหานี้ก็น่าประทับใจเช่นกัน
    เช่นบทความ “Anyone can Access Deleted and Private Repository Data on GitHub”
    ที่เปิดเผยกรณี ช่องโหว่การเข้าถึงข้อมูลใน GitHub repository ที่ถูกลบหรือเป็น private
    ครั้งนี้การวิเคราะห์ของพวกเขาก็ช่วยได้มากเช่นกัน