Lonjakan tagihan €54.000 dalam 13 jam: kunci browser Firebase tanpa pembatasan API digunakan untuk memanggil Gemini API

• Kunci browser Firebase terekspos tanpa pembatasan API, sehingga permintaan Gemini API dari luar terjadi secara otomatis, memicu tagihan besar dalam waktu singkat
• Biaya lebih dari €54.000 selama 13 jam ditagihkan tanpa kaitan dengan trafik pengguna nyata, dan peringatan biaya terlambat aktif sehingga respons ikut terlambat
• Tim dukungan Google Cloud mengklasifikasikan permintaan tersebut sebagai penggunaan valid (valid usage) dan menolak permintaan penyesuaian biaya
• Google akan memperkenalkan fitur perlindungan seperti batas pengeluaran, kunci autentikasi, pemblokiran kunci otomatis, dan pembayaran prabayar, serta menghentikan penggunaan kunci tanpa batas secara bertahap
• Pengembang harus tidak menyertakan kunci di kode klien, dan wajib menerapkan pembatasan API key serta batas anggaran

---

Kasus lonjakan tagihan Gemini API akibat kebocoran kunci browser Firebase

• Ringkasan insiden

  • Pada proyek yang sebelumnya hanya menggunakan Firebase Authentication, penggunaan Gemini API melonjak segera setelah Firebase AI Logic diaktifkan
  • Permintaan otomatis yang tidak terkait dengan trafik pengguna nyata terjadi dalam waktu singkat dan memicu tagihan lebih dari €54.000 selama sekitar 13 jam
  • Setelah API dinonaktifkan dan credential dirotasi, trafik abnormal berhenti
  • Peringatan anggaran (€80) dan peringatan deteksi anomali biaya aktif dengan keterlambatan beberapa jam; saat respons dilakukan, biaya sudah mencapai sekitar €28.000
  • Nilai tagihan akhir kemudian dikonfirmasi melebihi €54.000 akibat pelaporan biaya yang tertunda

• Hasil dari dukungan Google Cloud

  • Meski log dan materi analisis telah dikirim, permintaan tersebut diklasifikasikan sebagai penggunaan valid (valid usage) yang berasal dari proyek tersebut, sehingga permintaan penyesuaian biaya ditolak
  • Meskipun penggunaan ini abnormal dan bukan trafik yang digerakkan pengguna, sistem tetap memprosesnya sebagai tagihan normal

• Pertanyaan dari pengguna

  • Menanyakan apakah ada kasus serupa setelah mengaktifkan Firebase AI Logic atau Gemini
  • Menanyakan apakah ada langkah perlindungan tambahan selain App Check, kuota, dan migrasi ke pemanggilan server-side
  • Menanyakan apakah tersedia jalur eskalasi tambahan (escalation path) untuk kasus seperti ini

Tanggapan dari Google (Logan Kilpatrick)

• Fitur penagihan dan pembatasan penggunaan

  • Batas penagihan akun (billing account caps) untuk pengguna Gemini API telah diperkenalkan, dan pengguna Tier 1 akan diblokir otomatis setelah melewati batas bulanan $250
  • Batas pengeluaran per proyek (project spend caps) dapat diatur; sebagai contoh, akun pribadi dapat dibatasi ke $50
  • Semua pelaporan biaya memiliki keterlambatan sekitar 10 menit

• Keamanan API key dan perubahan yang akan datang

  • Penggunaan API key tanpa pembatasan (unrestricted key) akan segera dinonaktifkan di Gemini API

    • Pengguna baru secara default akan mendapatkan Auth key, yang memiliki keamanan lebih kuat dibanding sebelumnya
    • Jangan menyertakan key di kode klien; bila terekspos, hal itu dapat menimbulkan biaya
    • Tersedia fitur yang secara otomatis mendeteksi dan menonaktifkan key yang terekspos di web publik; dalam beberapa kasus nyata, pemblokiran terjadi dalam hitungan menit

• Pembatasan key dan cakupan layanan

  • Key yang dibuat di Google AI Studio secara default dibatasi hanya untuk Gemini API

    • Sebaliknya, key yang dibuat melalui jalur lain seperti Google Cloud Console dapat mengakses beberapa layanan, sehingga bila perlu harus diberi pembatasan per layanan

• Tindakan tambahan dan rencana ke depan

  • Meminta agar kasus tersebut dikirim langsung melalui email ke [e-mail] untuk ditinjau
  • Sistem penagihan prabayar (prepaid billing) telah diperkenalkan dan secara bertahap mengalihkan model ke pembayaran sebelum penggunaan
  • Saat ini sudah diterapkan untuk akun baru di Amerika Serikat dan sedang diperluas secara bertahap ke seluruh dunia
  • Langkah-langkah ini bertujuan memperkuat kontrol biaya pengembang dan pencegahan tagihan tak terduga

[GN⁺]

Pendapat Hacker News

• Kami menyiapkan alert anggaran (€80) dan alert anomali biaya, tetapi keduanya baru aktif beberapa jam terlambat
  Saat kami sempat merespons, biayanya sudah mencapai €28.000, dan pada akhirnya lebih dari €54.000 ditagihkan karena pelaporan biaya yang terlambat
  Dalam situasi seperti ini, alasan dari tiga perusahaan bahwa “hard spending cap secara teknis tidak mungkin” sama sekali tidak meyakinkan

  • Itulah sebabnya saya sebisa mungkin tidak menggunakan layanan seperti Google Cloud
    Mengatakan hard cap tidak mungkin itu tidak masuk akal, dan setidaknya pengguna harus diberi pilihan
  • Ini benar-benar gila. Membangun proyek yang bagus lalu harus menanggung €30.000~€50.000 karena satu kesalahan saja adalah pukulan yang bisa mengubah hidup
    Dulu kesalahan seperti ini cuma bug biasa, sekarang bisa berujung pada kebangkrutan
  • Hal seperti ini seharusnya ilegal
    Kalau Anda memesan penggantian ubin kamar mandi lalu ditagih untuk renovasi taman, tentu Anda berhak menolak
  • Sebagai manajer, saya menghindari Google Cloud karena bencana layanan pelanggan seperti ini
    Namun, dari pengalaman menangani sistem billing operator telekomunikasi, saya paham bahwa mengagregasi log berskala TB memang butuh waktu
    Meski begitu, operator biasanya memperhitungkan piutang macet sekitar 2~3% dan tetap berpihak pada pelanggan
    Google juga seharusnya memberikan respons yang lebih elegan dalam situasi seperti ini
    Terutama jika ini terjadi tepat setelah kunci AI terekspos, Google seharusnya mendeteksi pemindaian kunci dan memblokirnya
  • Menurut dokumentasi Gemini API, batas pengeluaran bulanan bisa diatur baik di level proyek maupun akun billing
    Namun, dalam praktiknya fitur ini tampaknya tidak benar-benar berfungsi

• Saya juga pernah mengalami hal serupa
  Saya menetapkan anggaran $100 di GCP, tetapi baru menerima email peringatan 5 jam setelahnya saat batas sudah terlampaui
  Mengejutkan bahwa fitur seperti ini bukan prioritas
  Mungkin pendapatan Google berkurang dalam jangka pendek, tetapi pengembang yang pernah mengalami ini tidak akan merekomendasikannya lagi

  • Saya marah setiap kali cerita seperti ini muncul
    Tim kami yang hanya berdua hampir bangkrut gara-gara runaway job
    Kami menghubungkan alert dengan kill switch sesuai rekomendasi GCP, tetapi alert baru datang 6 jam terlambat
    Pada akhirnya kami hanya bisa mendapat refund setelah menunjukkan bukti
    Google berkata “item barisnya terlalu banyak sehingga pipeline tertunda,” padahal bukankah sistem itu justru dibuat untuk menghadapi situasi seperti itu
  • Saya tidak mengerti bagaimana keterlambatan alert seperti ini bisa dianggap wajar
    Saya penasaran bagaimana penyelesaian biaya dengan Google pada akhirnya
  • Sebenarnya AWS juga tidak menjadikan fitur seperti ini sebagai prioritas
    Tidak ada cloud yang terburu-buru membuat fitur yang memutus aliran uang
  • Kalimat “mengorbankan kepercayaan jangka panjang demi pendapatan jangka pendek” sangat tepat
    Ini contoh khas late-stage capitalism

• Dari hasil pencarian GitHub, terlihat banyak token Gemini API yang terekspos begitu saja di repositori publik
  Google sudah lama tidak memperlakukan API key sebagai rahasia, lalu mendadak menganggap kunci LLM sebagai rahasia
  Kemungkinan besar penulis mengekspos kuncinya saat proses frontend atau berbagi kode

  • Masalah ini sebenarnya sudah lama dilaporkan, dan Google pernah mengatakan akan memblokir kunci yang bocor di Gemini API
    Ini juga tercantum di thread HN terkait dan dokumentasi resmi
    Jadi mengapa kasus seperti ini masih muncul lagi menjadi pertanyaan
  • Sebenarnya tidak ada kunci asli di hasil pencarian itu
  • Untuk kunci yang bocor, muncul pesan bahwa kunci akan langsung dinonaktifkan
    “Your API key was reported as leaked. Please use another API key.”
    Artinya, sebagian besar tampaknya diblokir secara otomatis
  • Tidak masuk akal jika API key tidak diperlakukan sebagai rahasia

• Di Google Cloud tidak ada cara mudah untuk menetapkan hard cap
  Saya sendiri menghabiskan lebih dari satu jam mencari pengaturannya, lalu akhirnya menemukan di Reddit cara Pub/Sub → Cloud Function → nonaktifkan billing
  Struktur seperti ini benar-benar gila

  • Tes favorit saya adalah meminta model Gemini untuk “menulis skrip yang mengambil penggunaan API sebuah proyek”
    Tingkat kegagalannya 100%
  • Ini pada dasarnya adalah jebakan pengguna (antifeature)
  • Mungkin memang sengaja dirancang seperti itu
    Jika perlindungan buatan pengguna gagal, lebih mudah untuk berkata “itu bukan tanggung jawab kami”
  • Tidak adanya fitur seperti ini berarti perusahaan kurang punya insentif untuk melindungi pengguna
  • AWS dan Azure juga sama saja
    Akan bagus jika ada fitur yang otomatis menjalankan kill-switch saat penggunaan melewati ambang batas
    Downtime 5 jam masih bisa diterima, tapi tagihan raksasa jelas tidak

• Setelah membaca postingan ini, saya langsung menurunkan paket Firebase saya
  Saya kaget melihat kasus orang yang ditagih $6.909 untuk API yang bahkan tidak pernah ia panggil selama sebulan
  Dulu saya juga pernah membuat API key saat sesi pelatihan, dan saya jadi berpikir mungkin saja kuncinya sempat tertangkap kamera di foto

  • Benarkah ada orang yang memotret kunci itu saat sesi tersebut? Saya penasaran apa penyebabnya

• Pada 2020~21 saya mengajar mahasiswa tentang layanan cloud menggunakan AWS Free Tier
  Saya menjalankan server MediaWiki, tetapi akun spam terus bermunculan dan keamanannya terasa rapuh
  Rasanya port jaringan selalu diserang
  Akhirnya saya sadar tidak ada cara membatasi anggaran ke $20~30, lalu saya meninggalkan AWS
  Cloud memang terlihat mudah dikelola, tetapi dari sisi bom biaya tanpa batas, ini berbahaya baik untuk individu maupun perusahaan

• Bagi pengembang solo atau tim kecil, public cloud adalah lingkungan yang menakutkan dan bikin cemas
  Tidak ada pengaman, dan biaya bisa melonjak tanpa batas
  Karena itu, sebagian besar waktu proyek habis untuk memantau biaya dan membuat logika pemutusan
  Dulu saya hanya memakai VPS sederhana, tetapi sekarang sering kali harus menggunakan layanan Google atau AWS
  Meski begitu, GCP terasa sedikit lebih baik karena bisa memutus keterkaitan akun billing secara terprogram

  • Saya penasaran apa yang terjadi jika kita tidak membayarnya begitu saja
    Di Amerika Serikat mungkin akan ada masalah hukum, tetapi saya tidak tahu bagaimana di negara lain

• Sistem billing seperti ini sangat buruk desainnya dari sudut pandang pengalaman pelanggan (CX)
  Billing berbasis event, jadi penggunaan menumpuk di antrean dan agregasinya terlambat
  Alert juga baru dikirim setelah agregasi selesai, sehingga jika ada keterlambatan, batasnya biasanya sudah terlewati jauh
  Struktur seperti ini hanya melindungi perusahaan, bukan pelanggan
  Kalau benar-benar berpusat pada pelanggan, begitu hard limit tercapai, jumlah di atas itu seharusnya tidak lagi ditagihkan
  Dengan begitu perusahaan akan punya motivasi untuk memperbaiki sistem agregasinya sendiri

  • Sebenarnya pendekatan berbasis event itu sendiri bukan masalah
    Seperti paket prabayar atau layanan dengan batas data, sistem potong saldo di muka sepenuhnya memungkinkan
    Pada akhirnya ini masalah praktik bisnis Google

• Menurut dokumentasi resmi Google Cloud, dalam keadaan darurat kita bisa menonaktifkan akun billing untuk menghentikan biaya
  Panduan resmi memperingatkan tentang “risiko kehilangan resource yang tidak dapat dipulihkan”
  Namun untuk aplikasi uji coba atau internal, ini adalah rem darurat yang bagus
  Dokumen alternatif lain dan dokumen pengaturan alert anggaran juga layak dirujuk

  • Namun, bisa ada keterlambatan beberapa jam hingga beberapa hari antara timbulnya biaya dan alert
    Saya pernah menghabiskan $400 hanya dalam 5 menit

• Kami juga mengalami masalah yang sama
  Kunci yang awalnya bukan rahasia berubah menjadi rahasia setelah Gemini API diaktifkan, tetapi tidak ada peringatan
  Untungnya kami menemukannya lebih awal lewat alert sehingga kerugian “hanya” dibatasi sampai $26.000
  Kami meminta refund ke tim dukungan Google, tetapi awalnya ditolak, dan sekarang sedang ditinjau ulang
  Dalam kasus seperti ini, isu seperti ini harus dieskalasikan setinggi mungkin ke level manajemen