API Key Leak Response Playbook untuk Tim Kecil

API key adalah salah satu rahasia paling sering bocor di aplikasi web. Penyebabnya bisa sederhana: key masuk ke repository, tercetak di log, terkirim ke frontend, tersimpan di screenshot, atau dikirim di chat internal. Untuk tim kecil, kebocoran API key sering terasa seperti masalah sepele sampai ada penyalahgunaan, biaya melonjak, data terakses, atau user terdampak.

Yang dibutuhkan bukan panik, tetapi playbook. Saat key bocor, tim harus tahu siapa melakukan apa, urutan langkahnya bagaimana, dan bukti apa yang harus dikumpulkan. Artikel ini membahas response plan yang realistis untuk tim kecil.

Langkah pertama: konfirmasi jenis key

Tidak semua key punya dampak sama. Identifikasi key yang bocor: apakah key untuk pembayaran, email, storage, analytics, internal API, atau layanan pihak ketiga. Catat environment-nya: development, staging, atau production. Catat juga scope akses: read-only, write, admin, atau billing.

Jangan langsung menghapus semua bukti. Kamu perlu tahu kapan key bocor, di mana muncul, dan apakah sudah dipakai pihak tidak sah.

Containment: batasi kerusakan

Jika key production bocor, prioritasnya adalah menghentikan akses. Revoke key lama atau disable sementara jika sistem mendukung. Jika tidak bisa revoke langsung, batasi IP, turunkan permission, atau matikan fitur yang memakai key tersebut sampai key baru siap.

Untuk key yang dipakai aplikasi live, rotasi harus hati-hati. Buat key baru, deploy konfigurasi baru, pastikan aplikasi sehat, baru revoke key lama. Jika revoke dulu tanpa pengganti, aplikasi bisa down.

Audit penggunaan

Setelah containment, cek log penggunaan. Cari request yang tidak biasa: IP asing, lonjakan request, endpoint sensitif, perubahan data, atau pola akses di luar jam normal. Untuk key pembayaran atau saldo, cocokkan dengan ledger transaksi. Untuk key email, cek volume kirim. Untuk key storage, cek file yang dibaca atau dihapus.

Jika vendor menyediakan audit log, ekspor atau screenshot data penting. Simpan waktu kejadian dalam timezone yang jelas agar timeline tidak membingungkan.

Rotasi key yang aman

1. Buat key baru dengan permission minimum.
2. Simpan di environment variable atau secret manager.
3. Deploy aplikasi dengan key baru.
4. Jalankan smoke test fitur terkait.
5. Revoke key lama.
6. Cek log untuk memastikan tidak ada request memakai key lama.
7. Catat perubahan di incident log.

Rotasi key tidak boleh hanya mengganti string. Pastikan semua worker, cron, queue, dan service background ikut memakai key baru. Banyak insiden berlanjut karena aplikasi utama sudah diganti tetapi worker lama masih memakai secret lama.

Komunikasi internal

Tim kecil tetap butuh komunikasi yang jelas. Tunjuk satu orang sebagai incident lead. Satu orang mengurus rotasi, satu orang audit log, satu orang mengecek dampak user jika perlu. Hindari semua orang menjalankan perintah produksi bersamaan tanpa koordinasi.

Gunakan format singkat: apa yang terjadi, key apa yang terdampak, sejak kapan, langkah containment, dampak sementara, dan next action.

Postmortem tanpa menyalahkan

Setelah aman, tulis postmortem. Fokus pada sistem, bukan menyalahkan orang. Pertanyaan penting: kenapa key bisa bocor, kenapa tidak terdeteksi lebih awal, kenapa scope key terlalu besar, dan kontrol apa yang perlu ditambahkan.

Pencegahan

• Jangan simpan key di repository.
• Gunakan secret scanning di Git.
• Masking secret di log.
• Jangan expose key ke frontend.
• Gunakan permission minimum.
• Pisahkan key development, staging, dan production.
• Rotasi berkala untuk key sensitif.
• Batasi akses admin yang bisa melihat key.

Checklist untuk repository

Tambahkan file environment ke .gitignore. Jalankan scanner sebelum commit. Review pull request yang menyentuh config, deploy script, atau dokumentasi. Jangan menaruh contoh key asli di README. Pakai placeholder yang jelas seperti YOUR_API_KEY.

Checklist untuk log

Log request boleh berguna, tetapi jangan log header Authorization penuh, token, password, key, OTP, atau secret. Jika perlu debugging, tampilkan beberapa karakter awal/akhir saja. Pastikan error handler tidak mencetak environment variable saat exception.

FAQ

Kalau key pernah masuk Git tapi sudah dihapus, apakah aman?

Belum tentu. Riwayat Git masih bisa menyimpan key lama. Anggap key sudah bocor dan rotasi.

Apakah cukup rename environment variable?

Tidak. Yang penting adalah mengganti key di sumber layanan dan revoke key lama.

Haruskah user diberi tahu?

Tergantung dampak. Jika ada data user, saldo, transaksi, atau akses akun yang berpotensi terdampak, komunikasi harus dipertimbangkan dengan serius.

Kesimpulan

API key leak bukan sekadar masalah string rahasia. Ia adalah incident security yang perlu containment, rotasi, audit, dan postmortem. Tim kecil bisa menangani dengan baik jika punya playbook yang jelas. Semakin cepat key direvoke, semakin kecil dampak. Semakin baik audit log, semakin mudah memastikan apakah ada penyalahgunaan.