ค่าใช้จ่ายพุ่ง €54,000 ภายใน 13 ชั่วโมง: มีการเรียก Gemini API ผ่าน Firebase browser key ที่ไม่มีการจำกัด API

• Firebase browser key ถูกเปิดเผยโดยไม่มีการจำกัด API ทำให้เกิด คำขอ Gemini API จากภายนอกแบบอัตโนมัติ และก่อให้เกิดค่าใช้จ่ายจำนวนมากในเวลาอันสั้น
• มีการเรียกเก็บเงินมากกว่า €54,000 ภายใน 13 ชั่วโมง โดย ไม่เกี่ยวข้องกับทราฟฟิกผู้ใช้จริง และ การแจ้งเตือนค่าใช้จ่ายทำงานล่าช้า ทำให้ตอบสนองได้ช้า
• ทีมสนับสนุน Google Cloud จัดประเภทคำขอเหล่านี้เป็น การใช้งานที่ถูกต้อง (valid usage) และ ปฏิเสธคำขอปรับยอดค่าใช้จ่าย
• Google กำลังเพิ่มฟีเจอร์ป้องกัน เช่น วงเงินใช้จ่าย, คีย์ยืนยันตัวตน, การบล็อกคีย์อัตโนมัติ, การชำระเงินล่วงหน้า และมีแผน ยุติการใช้คีย์แบบไม่จำกัดเป็นลำดับ
• นักพัฒนาควร ไม่ใส่คีย์ไว้ในโค้ดฝั่งไคลเอนต์ และต้องตั้งค่า การจำกัด API key และวงเงินงบประมาณ อย่างเคร่งครัด

---

กรณีค่าใช้จ่าย Gemini API พุ่งสูงจากการเปิดเผย Firebase browser key

• ภาพรวมเหตุการณ์

  • ในโปรเจ็กต์ที่เดิมใช้เพียง Firebase Authentication หลังจากเปิดใช้งาน Firebase AI Logic ก็พบว่า การใช้งาน Gemini API เพิ่มขึ้นอย่างรวดเร็ว
  • มี คำขออัตโนมัติ เกิดขึ้นในช่วงเวลาสั้น ๆ โดยไม่เกี่ยวกับทราฟฟิกผู้ใช้จริง ทำให้เกิดค่าใช้จ่ายมากกว่า €54,000 ภายในราว 13 ชั่วโมง
  • หลังจากปิด API และ หมุนเวียนข้อมูลรับรอง (credential) แล้ว ทราฟฟิกผิดปกติก็หยุดลง
  • การแจ้งเตือนงบประมาณ (€80) และ การแจ้งเตือนความผิดปกติของค่าใช้จ่าย ทำงานช้าหลายชั่วโมง ทำให้ตอนที่เริ่มตอบสนองนั้นมีค่าใช้จ่ายเกิดขึ้นแล้วราว €28,000
  • ยอดเรียกเก็บสุดท้ายถูกยืนยันว่าเกิน €54,000 เนื่องจาก การรายงานค่าใช้จ่ายล่าช้า

• ผลการติดต่อทีมสนับสนุน Google Cloud

  • แม้จะส่งล็อกและข้อมูลวิเคราะห์ไปแล้ว แต่คำขอถูกจัดว่าเป็น การใช้งานที่ถูกต้อง (valid usage) ที่เกิดจากโปรเจ็กต์ จึง ถูกปฏิเสธคำขอปรับยอดค่าใช้จ่าย
  • แม้การใช้งานดังกล่าวจะ ผิดปกติและไม่ใช่ทราฟฟิกที่ผู้ใช้เป็นผู้ก่อ แต่ในระบบกลับถูกคิดค่าใช้จ่ายเป็นการใช้งานปกติ

• ประเด็นที่ผู้ใช้สอบถาม

  • สอบถามว่าหลังเปิดใช้ Firebase AI Logic หรือ Gemini แล้ว มีกรณีคล้ายกันหรือไม่
  • ถามว่ามีมาตรการป้องกันเพิ่มเติมหรือไม่ นอกเหนือจาก App Check, quota และการย้ายไปเรียกจากฝั่งเซิร์ฟเวอร์
  • สอบถามว่ามี ช่องทางยกระดับการอุทธรณ์ (escalation path) สำหรับกรณีแบบนี้หรือไม่

คำตอบจากฝั่ง Google (Logan Kilpatrick)

• ฟีเจอร์ด้านการเรียกเก็บเงินและการจำกัดการใช้งาน

  • มีการเพิ่ม billing account caps สำหรับผู้ใช้ Gemini API แล้ว โดย ผู้ใช้ Tier 1 จะถูกบล็อกอัตโนมัติหลังถึงวงเงิน $250 ต่อเดือน
  • สามารถตั้งค่า project spend caps ได้ เช่น บัญชีส่วนตัวสามารถตั้งจำกัดไว้ที่ $50
  • รายงานการเรียกเก็บเงินทั้งหมดมี ความล่าช้าประมาณ 10 นาที

• ความปลอดภัยของ API key และการเปลี่ยนแปลง

  • การใช้ API key แบบไม่จำกัด (unrestricted key)จะถูกปิดใช้งานใน Gemini API เร็ว ๆ นี้

    • ผู้ใช้ใหม่จะได้รับ Auth key เป็นค่าเริ่มต้น ซึ่งมี ความปลอดภัยสูงกว่าเดิม
    • ไม่ควรใส่คีย์ไว้ในโค้ดฝั่งไคลเอนต์ เพราะหากคีย์รั่วอาจทำให้เกิดค่าใช้จ่ายได้
    • มีฟีเจอร์ที่สามารถ ตรวจจับและปิดใช้งานคีย์โดยอัตโนมัติเมื่อพบว่าถูกเปิดเผยบนเว็บสาธารณะ และมีกรณีที่ถูกบล็อกได้ภายในไม่กี่นาที

• การจำกัดคีย์และขอบเขตของบริการ

  • คีย์ที่สร้างจาก Google AI Studioจะถูกจำกัดให้ใช้กับGemini API เป็นค่าเริ่มต้น

    • ในทางกลับกัน คีย์ที่สร้างจากช่องทางอื่น เช่น Google Cloud Console สามารถเข้าถึง หลายบริการ ได้ จึงจำเป็นต้องตั้งค่า การจำกัดรายบริการ ตามความเหมาะสม

• มาตรการเพิ่มเติมและแผนในอนาคต

  • ขอให้ติดต่อทางอีเมลโดยตรง ([e-mail]) เพื่อช่วยตรวจสอบกรณีปัญหา
  • มีการนำระบบ prepaid billing มาใช้และกำลังเปลี่ยนไปสู่รูปแบบ ชำระก่อนใช้งาน
  • ขณะนี้ เริ่มใช้กับบัญชีใหม่ในสหรัฐฯ แล้ว และกำลังทยอยขยายไปทั่วโลก
  • มาตรการเหล่านี้มีเป้าหมายเพื่อ เสริมการควบคุมค่าใช้จ่ายของนักพัฒนาและป้องกันการถูกเรียกเก็บเงินโดยไม่คาดคิด

[GN⁺]

ความคิดเห็นจาก Hacker News

• เราตั้งทั้ง การแจ้งเตือนงบประมาณ (€80) และ การแจ้งเตือนเมื่อเกินค่าใช้จ่าย ไว้แล้ว แต่ทั้งสองอย่างทำงานช้ากว่าจริงหลายชั่วโมง
  ตอนที่เราเริ่มรับมือ ค่าใช้จ่ายก็พุ่งไปถึง €28,000 แล้ว และสุดท้ายก็ถูกเรียกเก็บเกิน €54,000 เพราะรายงานค่าใช้จ่ายล่าช้า
  คำแก้ตัวของทั้งสามบริษัทที่บอกว่า “hard spending cap เป็นไปไม่ได้ในทางเทคนิค” ฟังไม่ขึ้นในสถานการณ์แบบนี้

  • เพราะแบบนี้ฉันจึงพยายามหลีกเลี่ยงบริการอย่าง Google Cloud
    การบอกว่า hard cap ทำไม่ได้มันไร้สาระ อย่างน้อยก็ควรให้ผู้ใช้มีสิทธิ์เลือก
  • มันเหลือเชื่อจริง ๆ ระหว่างทำโปรเจกต์ดี ๆ อยู่แล้วพลาดครั้งเดียวกลับต้องจ่าย €30,000~€50,000 ซึ่งเป็น ความเสียหายระดับเปลี่ยนชีวิต
    เมื่อก่อนความผิดพลาดแบบนี้เป็นแค่บั๊กธรรมดา แต่ตอนนี้มันอาจพาไปถึงขั้นล้มละลายได้
  • เรื่องแบบนี้ควรผิดกฎหมาย
    ถ้าคุณจ้างให้เปลี่ยนกระเบื้องห้องน้ำ แต่กลับถูกคิดเงินค่าปรับปรุงสวน คุณก็ควรมีสิทธิ์ปฏิเสธตามปกติ
  • ในฐานะผู้จัดการ ฉันหลีกเลี่ยง Google Cloud เพราะ หายนะด้านบริการลูกค้า แบบนี้
    แต่จากประสบการณ์ที่เคยทำระบบคิดค่าบริการของบริษัทโทรคมนาคม ก็เข้าใจได้ว่าการรวม log ระดับ TB ต้องใช้เวลา
    เพียงแต่บริษัทโทรคมนาคมมักเผื่อ หนี้เสีย ไว้ราว 2~3% และคำนึงถึงลูกค้ามากกว่านี้
    Google เองก็ควร รับมือให้ดีกว่านี้ ในสถานการณ์แบบนี้
    โดยเฉพาะถ้าเรื่องนี้เกิดขึ้นทันทีหลังจากที่ AI key ถูกเปิดเผย Google ก็ควรตรวจจับการสแกนคีย์และบล็อกมันได้แล้ว
  • ตาม เอกสาร Gemini API บอกว่าสามารถตั้งลิมิตค่าใช้จ่ายรายเดือนได้ทั้งในระดับโปรเจกต์และระดับบัญชีการชำระเงิน
    แต่ในทางปฏิบัติดูเหมือนฟีเจอร์นี้จะทำงานได้ไม่ดีนัก

• ฉันก็เคยเจออะไรคล้าย ๆ กัน
  ตั้งงบไว้ $100 บน GCP แต่กลับได้รับ อีเมลแจ้งเตือนหลังจากเกินไปแล้ว 5 ชั่วโมง
  น่าตกใจที่ฟีเจอร์แบบนี้ไม่ถูกให้ความสำคัญ
  ระยะสั้นรายได้ของ Google อาจลดลง แต่ใครก็ตามที่เคยเจอประสบการณ์แบบนี้คงไม่แนะนำมันอีก

  • ทุกครั้งที่ได้ยินเรื่องแบบนี้ฉันจะหงุดหงิดมาก
    ทีม 2 คน ของเราเกือบพังเพราะ runaway job
    เราทำตามแนวทางที่ GCP แนะนำ โดยเชื่อมการแจ้งเตือนกับ kill switch แต่การแจ้งเตือนกลับมาช้าไป 6 ชั่วโมง
    สุดท้ายต้องยกหลักฐานให้ดูถึงจะได้เงินคืน
    Google บอกว่า “มี line item มากเกินไปจน pipeline ตัน” แต่ระบบนี้ก็ถูกสร้างมาเพื่อรับมือกับสถานการณ์แบบนั้นไม่ใช่หรือ
  • ฉันไม่เข้าใจเลยว่าการแจ้งเตือนล่าช้าแบบนี้ยอมรับกันได้อย่างไร
    สุดท้ายแล้ว Google จัดการเรื่องค่าใช้จ่ายกับคุณอย่างไรบ้างก็อยากรู้เหมือนกัน
  • ที่จริง AWS ก็ไม่ได้ให้ความสำคัญกับฟีเจอร์แบบนี้เช่นกัน
    ไม่มีคลาวด์เจ้าไหนรีบสร้าง ฟีเจอร์ตัดแหล่งรายได้ตัวเอง ก่อนหรอก
  • ประโยคที่ว่า “ทิ้งความเชื่อมั่นระยะยาวเพื่อรายได้ระยะสั้น” ตรงมาก
    นี่คือภาพแบบฉบับของ ทุนนิยมระยะปลาย

• จาก ผลการค้นหาใน GitHub จะเห็นว่ามีกรณีที่ Gemini API token ถูกเปิดเผยอยู่ใน public repository ตรง ๆ จำนวนมาก
  Google เคยปฏิบัติกับ API key มานานว่าไม่ใช่ความลับ แต่พอเป็นคีย์ของ LLM กลับเปลี่ยนมาถือเป็นความลับแบบกะทันหัน
  มีความเป็นไปได้สูงว่าผู้เขียนอาจเผลอเปิดเผยคีย์ระหว่างทำฟรอนต์เอนด์หรือแชร์โค้ด

  • เรื่องนี้มีการรายงานมานานแล้ว และ Google ก็เคยบอกว่าจะ บล็อกคีย์ที่รั่วไหลไม่ให้ใช้กับ Gemini API
    มีระบุไว้ทั้งใน เธรด HN ที่เกี่ยวข้อง และ เอกสารทางการ
    ก็เลยสงสัยว่าทำไมยังมีกรณีแบบนี้เกิดขึ้นอีก
  • จริง ๆ แล้วในผลการค้นหาไม่มีคีย์จริงอยู่
  • จะมีข้อความขึ้นมาว่าคีย์ที่รั่วถูก ทำให้ใช้ไม่ได้ ทันที
    “Your API key was reported as leaked. Please use another API key.”
    แปลว่าส่วนใหญ่น่าจะถูกบล็อกอัตโนมัติ
  • การบอกว่า API key ไม่ใช่ความลับนั้นฟังไม่สมเหตุสมผลเลย

• บน Google Cloud ไม่มีวิธีที่ง่ายในการตั้ง hard cap
  ฉันเองก็เสียเวลาเกินชั่วโมงไปกับการหา setting สุดท้ายถึงได้ไปเจอใน Reddit ว่าต้องทำแบบ Pub/Sub → Cloud Function → ปิด billing
  มันเป็นโครงสร้างที่ บ้าคลั่งสุด ๆ

  • การทดสอบที่ฉันชอบคือให้ Gemini model “เขียนสคริปต์ดึงปริมาณการใช้ API ของโปรเจกต์”
    ผลคือ ล้มเหลว 100%
  • เรื่องนี้แทบจะเป็น กับดักผู้ใช้ (antifeature) อยู่แล้ว
  • น่าจะเป็นการออกแบบโดยตั้งใจ
    ถ้าระบบป้องกันที่ผู้ใช้ทำเองล้มเหลว ก็พูดได้ง่ายว่า “ไม่ใช่ความรับผิดชอบของเรา”
  • การไม่มีฟีเจอร์แบบนี้หมายความว่าบริษัทมี แรงจูงใจไม่พอ ที่จะปกป้องผู้ใช้
  • AWS กับ Azure ก็เหมือนกัน
    ถ้ามีฟีเจอร์ที่ให้ kill-switch ทำงานอัตโนมัติเมื่อการใช้งานเกิน threshold ก็คงดี
    downtime 5 ชั่วโมงยังพอรับได้ แต่บิลมหาศาลนั้นรับไม่ไหวจริง ๆ

• พออ่าน โพสต์นี้ ฉันก็ไป ลดแพ็กเกจ Firebase ของตัวเองทันที
  ตกใจมากที่เห็นกรณีถูกเรียกเก็บ $6,909 จาก API ที่ตัวเองไม่ได้เรียกใช้เลยตลอดหนึ่งเดือน
  ฉันเองก็เคยสร้าง API key ระหว่าง session การสอนมาก่อน เลยคิดขึ้นมาว่าอาจมีใครถ่ายรูปติดไปก็ได้

  • หรือจะมีใครถ่ายคีย์จาก session นั้นจริง ๆ? ก็อยากรู้เหมือนกันว่าต้นเหตุมาจากอะไร

• ช่วงปี 2020~21 ฉันสอนนักเรียนใช้บริการคลาวด์และใช้ AWS Free Tier
  เราเปิด MediaWiki server ขึ้นมา แต่มีบัญชีสแปมโผล่มาเรื่อย ๆ และความปลอดภัยก็ดูน่ากังวล
  รู้สึกเหมือน network port ถูกโจมตีอยู่ตลอดเวลา
  สุดท้ายก็พบว่าไม่มีวิธีจำกัดงบไว้ที่ $20~30 ได้จริง เลยเลิกใช้ AWS
  แม้คลาวด์จะดูจัดการง่าย แต่ในแง่ของ ระเบิดค่าใช้จ่ายแบบไม่จำกัด มันเป็นความเสี่ยงทั้งต่อคนทั่วไปและบริษัท

• สำหรับนักพัฒนาเดี่ยวหรือทีมเล็ก ๆ public cloud เป็นสภาพแวดล้อมที่ น่ากลัวและชวนกังวล
  ไม่มีราวกันตก และค่าใช้จ่ายอาจพุ่งได้แบบไร้ขีดจำกัด
  เลยต้องใช้เวลาส่วนใหญ่ของโปรเจกต์ไปกับ การเฝ้าดูต้นทุนและตรรกะการตัดการทำงาน
  เมื่อก่อนฉันใช้ VPS ธรรมดา แต่ทุกวันนี้มักมีกรณีที่จำเป็นต้องใช้บริการของ Google หรือ AWS
  ถึงอย่างนั้น GCP ก็ยังดูดีกว่านิดหน่อยตรงที่สามารถ ตัดการเชื่อมบัญชีการชำระเงินด้วยโปรแกรมได้

  • ถ้าแค่ไม่จ่ายเงินไปเลยจะเกิดอะไรขึ้นนะ
    ในสหรัฐฯ คงมีปัญหาทางกฎหมาย แต่ในประเทศอื่นจะเป็นอย่างไรก็ไม่แน่ใจ

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

  • ที่จริงตัว event-based เองไม่ใช่ปัญหา
    ถ้าใช้วิธีหักล่วงหน้าแบบ แพ็กเกจเติมเงินหรือบริการที่มี data cap ก็ทำได้อยู่แล้ว
    สุดท้ายมันคือปัญหาด้าน แนวปฏิบัติทางธุรกิจ ของ Google

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

  • แต่ก็ยังอาจมี ความล่าช้าตั้งแต่หลายชั่วโมงถึงหลายวัน ระหว่างการเกิดค่าใช้จ่ายกับการแจ้งเตือน
    ฉันเคยเสีย $400 ภายใน 5 นาทีมาแล้ว

• พวกเราก็เจอปัญหาเดียวกัน
  คีย์ที่เดิมไม่ได้ถือเป็นความลับ กลับ ถูกเปลี่ยนให้เป็นคีย์ลับหลังเปิดใช้ Gemini API โดยไม่มีคำเตือน
  โชคดีที่เจอเร็วจากการแจ้งเตือน เลยจำกัดความเสียหายไว้ที่ $26,000
  เราขอเงินคืนจากทีมซัพพอร์ตของ Google แต่ตอนแรกโดนปฏิเสธ ตอนนี้กำลังอยู่ระหว่างการพิจารณาใหม่
  ในกรณีแบบนี้ต้อง escalate ประเด็นให้ขึ้นไปถึงหน่วยงานระดับสูงที่สุดเท่าที่ทำได้