- Selama lebih dari 10 tahun, Google menyatakan bahwa kunci API bukan rahasia dan aman untuk dipublikasikan, tetapi setelah Gemini API diaktifkan, kunci yang sama berubah menjadi sarana autentikasi sensitif
- Kunci publik yang sebelumnya digunakan di Google Maps, Firebase, dan lain-lain otomatis memperoleh hak akses ke Gemini API, sehingga kunci yang terekspos bisa dipakai untuk mengakses data pribadi dan menimbulkan tagihan
- Truffle Security mengonfirmasi bahwa 2.863 kunci API Google yang benar-benar digunakan terekspos di internet, dan sebagian di antaranya mencakup kunci milik layanan Google sendiri
- Google mengakui masalah ini dan sedang menerapkan pemblokiran kunci bocor, default khusus Gemini, serta fitur notifikasi kebocoran, tetapi audit retroaktif untuk kunci lama masih belum selesai
- Kasus ini menunjukkan risiko perluasan hak akses kredensial lama akibat integrasi fitur AI, dan developer perlu segera memeriksa apakah Gemini API aktif serta apakah kuncinya terekspos
Masalah inti
- Google Cloud menggunakan struktur kunci API tunggal berformat
AIza..., yang sekaligus menjalankan dua fungsi: identifikasi publik dan autentikasi sensitif
- Di masa lalu, Google secara eksplisit menyatakan kepada developer bahwa kunci API aman disertakan langsung di kode klien
- Di checklist keamanan Firebase juga disebutkan bahwa “API key is not a secret”
- Namun ketika Gemini API diaktifkan, semua kunci API pada project yang sudah ada otomatis memperoleh hak akses ke endpoint Gemini
- Hak akses ini meluas tanpa peringatan, tanpa proses konfirmasi, dan tanpa email notifikasi
- Hal ini memunculkan dua masalah
- Perluasan hak akses retroaktif (Retroactive Privilege Expansion): kunci Maps yang dulu dipublikasikan berubah menjadi kredensial akses Gemini
- Default yang tidak aman (Insecure Defaults): saat membuat kunci baru, default-nya adalah “Unrestricted”, sehingga dapat mengakses semua API termasuk Gemini
- Akibatnya, ribuan token untuk penagihan berubah menjadi kredensial autentikasi nyata dan terekspos di internet
Skenario serangan yang mungkin
- Penyerang dapat menyalin kunci
AIza... dari source code situs web lalu mengakses Gemini API hanya dengan permintaan curl sederhana
- Dengan cara ini, penyerang dapat
- Mengakses data nonpublik (
/files/, /cachedContents/ endpoint)
- Membebankan biaya penggunaan Gemini API
- Menghabiskan kuota hingga menyebabkan gangguan layanan
- Penyerang tidak perlu menembus infrastruktur korban; cukup mengambil kunci dari halaman web publik untuk melancarkan serangan
Skala kunci yang terekspos
- Truffle Security menganalisis dataset Common Crawl November 2025 (sekitar 700TiB) dan menemukan 2.863 kunci API Google aktif
- Kunci-kunci ini semula digunakan untuk layanan publik seperti Google Maps, tetapi memiliki hak akses ke Gemini API
- Korban mencakup lembaga keuangan, perusahaan keamanan, perusahaan rekrutmen global, hingga Google sendiri
- Bahkan Google juga terekspos pada risiko struktural yang sama
Kasus kunci internal Google
- Truffle Security mendemonstrasikan akses Gemini API menggunakan kunci yang disertakan dalam source code publik situs produk Google
- Kunci tersebut sudah dipublikasikan sejak sebelum Februari 2023 dan awalnya hanya dipakai untuk identifikasi project sederhana
- Saat memanggil endpoint
/models, kunci itu mengembalikan respons normal (200 OK), yang mengonfirmasi akses ke API sensitif dimungkinkan
- Artinya, kunci yang dulu tidak berbahaya memperoleh hak sensitif tanpa campur tangan developer
Laporan kerentanan dan linimasa respons
- 21 November 2025: dilaporkan ke Google VDP
- 25 November: Google menilai ini sebagai “perilaku yang dimaksud”
- 1–2 Desember: setelah Truffle Security menunjukkan kasus kunci internal Google, Google mengklasifikasikannya ulang sebagai bug dan menaikkan tingkat keparahan
- 12 Desember: Google mulai memperluas pipeline deteksi kunci bocor dan membatasi akses Gemini
- 13 Januari 2026: Google mengklasifikasikan kerentanan ini sebagai “Single-Service Privilege Escalation (READ)”
- 2 Februari: dikonfirmasi bahwa perbaikan akar masalah sedang berlangsung
Tindak lanjut Google
- Dalam dokumentasi resmi, Google mengumumkan rencana penguatan keamanan berikut
- Scoped defaults: kunci baru yang dibuat di AI Studio hanya mengizinkan akses khusus Gemini
- Leaked key blocking: memblokir otomatis akses Gemini API dari kunci yang bocor
- Proactive notification: mengirim notifikasi segera kepada pengguna saat kunci bocor terdeteksi
- Beberapa perbaikan sudah berjalan, tetapi audit retroaktif dan pemberitahuan pengguna untuk kunci lama yang terekspos masih belum selesai
Panduan pengecekan untuk developer
- Langkah 1: Periksa di semua project GCP apakah Generative Language API diaktifkan
- Langkah 2: Jika aktif, identifikasi kunci yang berstatus ‘Unrestricted’ atau mencakup Gemini di pengaturan API key
- Langkah 3: Pastikan apakah kunci tersebut terdapat di kode publik atau halaman web
- Jika terekspos, kunci harus segera dirotasi (rotating)
- Bonus: Gunakan tool TruffleHog untuk mendeteksi otomatis kunci aktif yang dapat mengakses Gemini
- Contoh perintah:
trufflehog filesystem /path/to/your/code --only-verified
Kesimpulan
- Kasus ini menunjukkan risiko struktural ketika penambahan fitur AI membuat kredensial publik lama memperoleh hak sensitif
- Google sudah menyadari masalah ini dan sedang menanganinya, tetapi pentingnya default yang aman dan desain pemisahan kunci kembali menjadi sorotan
- Developer dan perusahaan harus segera memeriksa status aktivasi Gemini API serta paparan kunci mereka
1 komentar
Opini Hacker News
Dokumentasi Google AI Studio merekomendasikan distribusi aplikasi melalui open proxy
Pendekatan ini membuat orang keliru mengira API key aman karena berada di balik proxy, padahal pada praktiknya hal itu memungkinkan penyalahgunaan tagihan AI
Bahkan aplikasi yang sama sekali tidak memiliki fitur AI pun terekspos ke model berbiaya tinggi jika cakupan key tidak dibatasi secara manual
Aplikasi-aplikasi yang rentan seperti ini bisa ditemukan dengan mudah hanya lewat pencarian di Google, Twitter, atau Hacker News
Analisis terkait dirangkum dalam tulisan ini
Google mengatakan akan memblokir key yang bocor, tetapi sejak awal mereka tidak memperlakukan key tersebut sebagai rahasia
Idealnya, semua key yang dibuat sebelum peluncuran Gemini seharusnya dicegah agar tidak bisa mengakses Gemini
Jika sistem deteksi kebocoran menghasilkan false positive, ada risiko key Gemini yang sah ikut terblokir
Paling tidak, izin Generative Language API harus dihapus dari semua key lama, tetapi itu pun bukan solusi yang sepenuhnya tuntas
Pada akhirnya, bisa jadi izin tersebut harus dihapus secara massal dari semua key
Itu akan merusak sangat banyak aplikasi, dan menjadi alasan Google enggan mengakui masalahnya
Yang lebih serius, key tersebut juga mengekspos cached context dan data unggahan
Ditemukan bahwa key Google yang di-hardcode dalam image Android lama ternyata benar-benar bisa digunakan untuk Gemini
Sebagian sudah dipakai banyak orang sehingga terkena rate limit, tetapi beberapa masih tetap berfungsi
Sekitar dua bulan lalu, key-key ini dianggap bocor dan semuanya dinonaktifkan
Key yang dibuat sejak lama awalnya ditujukan hanya untuk layanan terbatas seperti Firebase atau Firestore
Namun setelah Gemini diluncurkan, akses Gemini pada key yang sudah ada diaktifkan secara otomatis, sehingga penyalahgunaan menjadi mudah
Key publik yang disertakan di file APK pada akhirnya langsung berubah menjadi key akses Gemini
Misalnya, developer X membuat key untuk Maps, lalu developer Y mengaktifkan Gemini dalam project yang sama
Maka key milik X akan memperoleh hak akses ke Gemini
Karena itu, hindari memakai ulang project, dan gunakan project GCP terpisah untuk tiap layanan
Muncul pertanyaan kenapa cacat keamanan yang begitu jelas tidak tersaring lebih awal
Untuk perusahaan besar seperti Google, seharusnya ada pengujian atau spesifikasi yang terstandarisasi
Semakin besar dan rumit organisasinya, semakin banyak pula blind spot pengawasan seperti ini
tetapi mereka tetap terpaku pada soal membalik binary tree
Situasi ini mengingatkan pada penyalahgunaan SSN (Social Security Number) di masa lalu
Awalnya hanya nomor untuk identifikasi sederhana, tetapi begitu mulai dipakai sebagai key autentikasi, masalah pun membesar
Demi implementasi yang cepat dan murah, pada akhirnya biaya justru dibebankan ke pengguna
Google tampaknya masih belum benar-benar menyelesaikan masalah ini
Ini adalah kesalahan besar yang lahir dari peluncuran Gemini yang tergesa-gesa,
dan untuk memperbaikinya mereka kemungkinan harus menonaktifkan key lama, yang bisa merusak workflow pelanggan
Dari sudut pandang Google, ini juga merupakan kerusakan citra yang sangat serius
Ini adalah semacam masalah Retroactive Privilege Expansion
Seseorang mungkin telah memublikasikan key Maps lama di situs web, lalu ketika developer lain dalam tim mengaktifkan Gemini,
key publik itu langsung berubah menjadi kredensial akses Gemini
Akibatnya, siapa pun bisa memakai key tersebut untuk mengakses upload file atau data cache
Pengguna yang mengikuti dokumentasi lama dan memakai key publik kini justru dirugikan
Penyerang bisa mencuri key itu dan memicu ledakan tagihan
Penjelasan sederhananya, ribuan API key lama yang semula hanya token penagihan
tiba-tiba berubah menjadi kredensial akses Gemini
Maps API key awalnya dirancang agar pengguna bisa mendapat layanan peta sambil pembayarannya dibebankan ke kartu saya
Masalahnya, sekarang key seperti itu juga bisa dipakai untuk mengakses Gemini
Seharusnya dibuat project internal terpisah agar key-key tersebut terisolasi,
tetapi demi rilis cepat mereka memakai begitu saja kode hasil generasi LLM, lalu saat muncul masalah mereka menyalahkan Google
Riset sebelumnya dari perusahaan keamanan yang menganalisis masalah ini juga mengesankan
Misalnya, ada kasus pengungkapan celah akses ke data repositori GitHub yang sudah dihapus dan privat seperti dalam artikel “Anyone can Access Deleted and Private Repository Data on GitHub”
Kali ini pun analisis mereka sangat membantu