Cara Mengamankan Google API Key Biar Gak Bocor & Nguras Tagihan

tl;dr: API key yang bocor = orang lain bisa numpang kuota kamu dan bikin tagihan meledak. Cara ngamaninnya ada empat lapis: (1) jangan pernah hardcode key di kode atau push ke GitHub—pakai .env, (2) restrict key (batasi API mana yang boleh + dari domain/IP mana), (3) pasang quota limit + billing alert biar lonjakan mencurigakan ketahuan cepat, dan (4) rotasi key berkala + hapus yang gak dipakai. Artikel ini bahas satu-satu, plus apa yang harus dilakukan kalau key kamu terlanjur bocor.

Ini skenario yang beneran sering kejadian: seseorang bikin API key buat proyek kecil, nulis key-nya langsung di kode, lalu push ke repository GitHub publik. Dalam hitungan menit, bot scanner nemuin key itu, dan tiba-tiba ada ribuan request dari orang gak dikenal yang numpang kuota—ujungnya tagihan bengkak berkali lipat. Kabar baiknya: semua ini bisa dicegah dengan beberapa langkah sederhana. Kalau kamu baru aja bikin API key pertama kamu, artikel ini wajib dibaca sebelum key itu kepakai di produksi.

Kenapa API key yang bocor berbahaya?

Inti masalahnya: API key gak ngidentifikasi siapa yang manggil. Dia cuma nandain request itu punya project mana (buat billing dan kuota). Artinya, siapa pun yang megang key-nya bisa memakainya seolah-olah dia kamu—gak ada verifikasi identitas. Ini beda fundamental dari OAuth, yang kita bahas terpisah di panduan API Key vs Service Account vs OAuth.

Konsekuensinya kalau bocor:

Tagihan bengkak. Orang lain pakai kuota kamu buat API berbayar—kamu yang ditagih.
Kuota habis. Aplikasi kamu sendiri jadi kena limit gara-gara dipakai orang lain.
Akun berisiko di-suspend. Kalau pemakaian mencurigakan terdeteksi, Google bisa membekukan proyek kamu.

Lapis 1: Jangan pernah hardcode key di kode

Ini kesalahan paling umum dan paling fatal. Google secara eksplisit merekomendasikan: jangan menyematkan API key langsung di dalam kode. Key yang ditulis di source code gampang banget ke-ekspos—cukup kamu lupa hapus sebelum share, atau file-nya ke-commit ke Git.

Yang benar:

Simpan key di environment variable atau file di luar source tree aplikasi.
Kalau pakai file .env, wajib masukin ke .gitignore supaya gak ikut ke-push.
Untuk skala serius, pakai secret manager (misal Google Secret Manager) daripada file biasa.

Contoh pola aman di kode: alih-alih nulis key-nya langsung, kamu panggil dari environment—misalnya process.env.API_KEY (Node.js) atau os.environ["API_KEY"] (Python). Key-nya sendiri gak pernah muncul di file yang kamu commit.

Lapis 2: Restrict API key kamu

Google merekomendasikan selalu membatasi key dengan minimal satu jenis restriction. Ada dua kategori:

Application restrictions (batasi SIAPA yang boleh pakai)

Membatasi dari mana key boleh dipakai. Pilihannya tergantung jenis aplikasi:

HTTP referrer — buat aplikasi web; key cuma jalan kalau request datang dari domain yang kamu izinin (misal *.situskamu.com).
IP address — buat backend/server; key cuma jalan dari IP yang terdaftar.
Android/iOS app — key diikat ke aplikasi mobile spesifik.

API restrictions (batasi UNTUK APA key dipakai)

Membatasi API mana aja yang boleh dipanggil pakai key ini. Kalau proyek kamu punya banyak API aktif tapi key ini cuma perlu satu (misal cuma Maps, atau cuma Gemini), batasi ke API itu aja. Google merekomendasikan pasang kedua jenis restriction sekaligus untuk perlindungan maksimal.

Semua ini diatur di halaman Credentials di Google Cloud Console—pilih key yang mau dibatasi, lalu set restriction-nya.

Lapis 3: Pasang quota limit dan billing alert

Restriction mengurangi risiko, tapi lapisan pengaman terakhir buat mencegah tagihan bengkak adalah batas pemakaian + notifikasi:

Quota limits. Set batas maksimal request per hari/menit di Google Cloud Console. Kalau ada lonjakan gak wajar, pemakaian otomatis berhenti di batas itu—bukan terus jalan sampai tagihan meledak.
Billing alerts / budget. Buat budget di Cloud Billing dan pasang alert (misal notifikasi email kalau pemakaian sudah 50%, 90%, 100% dari budget). Kamu langsung tahu kalau ada yang gak beres, bukan kaget pas tagihan datang.

Kombinasi ini penting: quota limit membatasi teknis, billing alert kasih peringatan dini. Keduanya murah dipasang (gratis) tapi bisa nyelametin kamu dari tagihan ratusan dollar.

Lapis 4: Rotasi berkala dan hapus key yang gak dipakai

Hapus key yang gak diperlukan. Setiap key yang masih aktif adalah permukaan serangan. Kalau ada key lama yang gak kepakai, hapus.
Rotasi key secara berkala. Google menyediakan fitur “Rotate key” di halaman Credentials—generate key baru, update aplikasi kamu ke key baru, lalu hapus key lama. Ini membatasi dampak kalau ada key yang diam-diam sudah bocor tanpa kamu sadari.

Kalau API key kamu terlanjur bocor, lakukan ini

Jangan panik, tapi bertindak cepat—ini urutan yang benar:

Rotasi (ganti) key yang bocor segera. Generate key baru dan pindahkan aplikasi ke key baru. Ini langkah paling penting dan mendesak—key lama yang bocor harus dianggap sudah dikuasai orang lain.
Hapus/nonaktifkan key lama setelah aplikasi berhasil pindah ke key baru.
Cek billing dan log pemakaian untuk lonjakan mencurigakan selama key bocor. Kalau ada pemakaian abnormal, laporkan ke Google Cloud Support.
Bersihkan jejak di repository. Kalau key ke-commit ke Git, menghapusnya dari commit terakhir saja tidak cukup—key masih ada di riwayat commit. Anggap key itu permanen bocor (makanya langkah 1 wajib), dan bersihkan riwayat kalau perlu.

Prinsip penting: begitu key kelihatan publik walau sedetik, anggap dia sudah bocor selamanya. Jangan coba “menyembunyikan” ulang key yang sama—ganti dengan yang baru.

Ringkasan checklist keamanan API key

☐ Key disimpan di environment variable / secret manager, bukan hardcode
☐ File .env sudah masuk .gitignore
☐ Application restriction aktif (HTTP referrer / IP / app)
☐ API restriction aktif (batasi ke API yang dipakai saja)
☐ Quota limit terpasang
☐ Billing budget + alert terpasang
☐ Key lama yang gak dipakai sudah dihapus
☐ Ada jadwal rotasi key berkala

Pertanyaan yang Sering Ditanya

Apa yang terjadi kalau Google API key saya bocor?

Siapa pun yang menemukan key-nya bisa memakainya seolah-olah kamu—karena API key tidak memverifikasi identitas. Risikonya: tagihan membengkak (mereka numpang kuota berbayar kamu), kuota aplikasimu sendiri habis, dan proyek berisiko dibekukan Google kalau terdeteksi pemakaian mencurigakan. Kalau bocor, segera rotasi (ganti) key-nya.

Bagaimana cara restrict API key di Google Cloud Console?

Buka halaman Credentials di Google Cloud Console, pilih API key yang mau dibatasi, lalu atur dua hal: Application restrictions (HTTP referrer untuk web, IP address untuk server, atau app untuk mobile) dan API restrictions (pilih hanya API yang key ini boleh panggil). Google merekomendasikan mengaktifkan kedua jenis restriction sekaligus.

Apakah menaruh API key di file .env sudah cukup aman?

File .env membantu memisahkan key dari kode, tapi hanya aman kalau file itu masuk .gitignore sehingga tidak ikut ter-commit ke repository. .env yang ter-push ke GitHub sama bahayanya dengan hardcode. Untuk keamanan lebih tinggi di produksi, gunakan secret manager, bukan sekadar file .env.

Bagaimana cara mencegah tagihan Google Cloud membengkak?

Pasang quota limit (batas request per hari/menit) supaya pemakaian berhenti otomatis saat mencapai batas, dan buat billing budget dengan alert di Cloud Billing supaya kamu dapat notifikasi saat pemakaian mendekati atau melewati anggaran. Dua-duanya gratis dipasang dan mencegah kejutan tagihan.

Kalau key sudah ter-push ke GitHub, cukup dihapus dari kode?

Tidak cukup. Menghapus key dari commit terbaru tidak menghilangkannya dari riwayat commit—key masih bisa ditemukan di history. Anggap key itu sudah bocor permanen: langkah wajibnya adalah membuat key baru dan menonaktifkan yang lama, bukan sekadar menghapus dari file.

Seberapa sering sebaiknya rotasi API key?

Tidak ada aturan baku, tapi rotasi berkala (misalnya tiap beberapa bulan) adalah praktik baik untuk membatasi dampak kebocoran yang mungkin tidak kamu sadari. Google menyediakan fitur Rotate key di halaman Credentials. Selain berkala, rotasi wajib segera dilakukan begitu kamu curiga key sudah bocor.

Penutup

Mengamankan API key bukan soal ribet, tapi soal disiplin beberapa kebiasaan sederhana: jangan hardcode, selalu restrict, pasang quota + billing alert, dan rotasi berkala. Empat lapis ini murah dipasang tapi bisa menyelamatkan kamu dari tagihan ratusan dollar dan sakit kepala.

Kalau kamu lagi serius membangun AI agent yang aman dari nol—termasuk cara mengelola kredensial dengan benar biar gak jadi celah—kamu bisa belajar terstruktur lewat workshop KomuniTech (2 jam, langsung praktik bikin Karyawan AI sendiri, plus sertifikat sebagai peserta).

Referensi

Disclaimer: Detail antarmuka Google Cloud Console dan kebijakan kuota/billing bisa berubah sewaktu-waktu. Selalu cek dokumentasi resmi Google untuk informasi terkini.

Artikel telah diupdate pada 05/08/2026 untuk memastikan artikel tetap sesuai kondisi terkini.