API key bocor di aplikasi vibe coding: cara cek sendiri dalam 5 menit

Anda membangun aplikasi dengan bantuan AI: chat ke model, tempel kode, deploy. Aplikasinya jalan, tampilannya bagus, dan pengguna mulai datang. Yang sering tidak ikut diperiksa: apakah kunci API — OpenAI, Supabase, Google, Stripe, Firebase — ikut terkirim ke browser pengunjung. Kalau iya, kunci itu bukan lagi milik Anda.

Ini bukan skenario teoretis. Untuk menguji sensor websecrets milik AISG, kami menanam kunci palsu di sebuah halaman publik milik sendiri, lalu memindainya. Hasilnya critical: kunci terbaca dari aset klien, nilainya disamarkan di laporan, tapi keberadaannya tidak bisa dibantah. Catatan penting soal kejujuran: itu canary milik kami sendiri, bukan aplikasi orang lain — dan sampai hari ini AISG belum pernah memindai aplikasi pihak ketiga.

Kenapa ini sering terjadi di aplikasi buatan AI

Tiga pola yang berulang:

• Kunci ditempel di kode front-end karena cara tercepat agar "langsung jalan" adalah menaruh VITE_OPENAI_KEY atau NEXT_PUBLIC_... di berkas yang dikirim ke browser. Awalan NEXT_PUBLIC_ dan VITE_ berarti variabel itu memang dipublikasikan.
• Berkas lingkungan ikut ter-deploy. .env atau folder .git ikut terunggah ke hosting statis, lalu bisa diunduh siapa pun yang menebak URL-nya.
• Source map ikut publik. Berkas .js.map memberi kembali kode sumber asli Anda — termasuk komentar dan kunci yang sudah "dihapus" dari build.

Empat gejala yang bisa Anda periksa sendiri, tanpa alat

1. Cari pola kunci di halaman. Buka aplikasi Anda, tekan Ctrl+U (view source), lalu cari sk-, AIza, supabase.co, service_role. Kalau muncul di HTML, itu sudah cukup untuk berhenti dan memperbaiki.
2. Periksa bundle JavaScript. Buka DevTools → tab Network → muat ulang halaman → klik berkas .js terbesar → cari pola yang sama. Bundler tidak menghapus kunci; ia hanya memperkecil teks.
3. Tes berkas yang tidak seharusnya ada. Buka https://domain-anda/.env dan https://domain-anda/.git/HEAD. Jawaban yang benar adalah 404. Kalau salah satunya menampilkan isi, itu kebocoran, bukan temuan teoretis.
4. Cek source map. Buka https://domain-anda/assets/index.js.map (atau nama berkas bundle Anda). Kalau terunduh, kode sumber Anda publik.

Delapan hal yang diperiksa scan permukaan AISG

Free URL scan di /#free-scan tidak butuh akun dan tidak butuh instalasi. Yang dijalankan hanya pembacaan, bukan eksploitasi:

1. Redirect HTTP → HTTPS dan masa berlaku sertifikat TLS.
2. Header keamanan (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) dan atribut cookie.
3. CORS: apakah server membuka akses untuk semua origin (*).
4. Berkas terbuka: /.env, /.git/HEAD, /.git/config.
5. Rahasia di aset JavaScript: pola kunci per provider.
6. Rahasia inline di HTML (kunci yang ditulis langsung di halaman — kasus yang lolos kalau pemindai hanya mengikuti <script src>).
7. Source map yang terpublikasi.
8. SPF dan DMARC domain (apakah email atas nama domain Anda bisa dipalsukan).

Nilai rahasia yang ditemukan selalu disamarkan di laporan — cukup beberapa karakter awal dan panjangnya — supaya laporan tidak menjadi kebocoran baru.

Yang TIDAK bisa dilihat scan permukaan (batas yang harus Anda tahu)

• Tidak melihat kode server, database, atau isi repo. Scan ini hanya melihat apa yang publik.
• Tidak membuktikan eksploitasi. Temuan adalah indikasi dan wajib diverifikasi manusia.
• Kuotanya satu scan gratis per alamat IP (selamanya) dan satu laporan PDF. Hasil kosong bukan jaminan aman — artinya hanya "yang diperiksa tidak menemukan", dan bagian coverage di laporan menyebutkan pemeriksaan yang gagal.
• Untuk memeriksa kode, riwayat git, dependensi, IaC, dan aturan data-layer, Anda butuh scan lokal dari worker (Community gratis untuk mulai).

Kalau ketemu, urutan perbaikannya

1. Rotasi kunci lebih dulu, jangan menunggu kode diperbaiki. Kunci yang sudah bocor harus dianggap dipakai orang lain.
2. Pindahkan panggilan ke sisi server — API route, serverless function, atau edge function. Browser hanya berbicara dengan server Anda, bukan langsung ke provider.
3. Bersihkan riwayat kalau kunci pernah di-commit: hapus dari riwayat git, bukan hanya dari commit terakhir.
4. Deploy ulang, lalu cek ulang. Untuk URL, gunakan jalur re-check dari akun (bukan kuota IP), supaya perbaikan bisa dibuktikan, bukan diasumsikan.

Kesimpulannya sederhana: kebocoran kunci API bukan soal kepintaran menulis kode, tapi soal tahu apa yang benar-benar terkirim ke browser. Empat pemeriksaan di atas bisa Anda lakukan sekarang, tanpa akun, tanpa memasang apa pun.