Apakah Vibe Coding Aman? Ini 7 Risiko Nyata dan Cara Menutupnya

"Apakah vibe coding aman?" adalah pertanyaan yang sedikit salah alamat. Vibe coding — membangun aplikasi dengan mengarahkan model AI dan meninjau hasilnya sambil jalan — tidak berbahaya karena alatnya. Yang berbahaya adalah hal-hal yang biasanya tidak diperiksa karena semua terasa cepat dan sudah "jalan di laptop saya".

Artikel ini tidak akan menakut-nakuti dengan statistik yang tidak bisa Anda verifikasi. Isinya: apa yang secara mekanis berubah ketika kode ditulis dengan bantuan AI, tujuh pola risiko yang paling sering muncul, dan urutan konkret untuk menutupnya sebelum aplikasi dipakai orang lain.

Apa yang sebenarnya berubah saat AI menulis kode

Model bahasa diarahkan untuk menghasilkan sesuatu yang berfungsi. Fungsi itu diuji dengan cara yang paling mudah: tombol mengklik, data muncul, halaman tidak error. Persyaratan seperti "hanya pemilik data yang boleh melihatnya" tidak muncul sebagai error di layar — jadi tidak pernah terlihat gagal.

Praktisnya ada tiga pola yang berulang:

• Yang rahasia ditaruh di tempat yang paling mudah. Agar aplikasi langsung jalan, kunci API sering ditempel di kode frontend atau di berkas konfigurasi yang ikut terunggah.
• Validasi dan izin ditunda. Pemeriksaan dilakukan di tampilan (tombol disembunyikan), bukan di server. Tampilan bisa dilewati; server tidak.
• Konfigurasi memakai setelan paling longgar. Aturan akses basis data dimatikan agar data "kelihatan", CORS dibuka lebar agar tidak kena error, dan lingkungan pengembangan dipakai juga di produksi.

Tujuh risiko yang paling sering muncul

1. Kunci API tertanam di sisi depan

Kunci yang ditulis di JavaScript, di dalam HTML, atau di variabel lingkungan yang diawali NEXT_PUBLIC_ akan terkirim ke browser setiap pengunjung. Siapa pun bisa membuka DevTools atau melihat berkas bundle dan mengambilnya. Perbaikannya bukan menyamarkan kunci, tapi memindahkan panggilan ke server. Cara memeriksanya ada di artikel API key bocor.

2. .env dan .git ikut terunggah

Dua berkas ini tidak boleh bisa diakses dari internet. Kalau bisa, isi .env memberi kunci basis data, dan folder .git memberi riwayat kode lengkap — termasuk kunci yang pernah Anda hapus. Langkah cepatnya ada di artikel .env dan .git.

3. Aturan akses basis data dimatikan

Pada layanan seperti Supabase atau Firebase, tabel yang aturan aksesnya longgar bisa dibaca dengan kunci publik yang memang dirancang untuk publik. Aplikasi tetap tampak normal karena yang salah bukan tampilannya, melainkan izin di lapisan data. Ini dijelaskan panjang di artikel RLS Supabase.

4. Endpoint tanpa pemeriksaan sesi

UI menyembunyikan menu admin, tapi /api/admin/users tetap menjawab kalau dipanggil langsung. Cara membuktikannya sederhana: ambil satu request dari DevTools, kirim ulang tanpa header otorisasi. Kalau tetap 200, izinnya ada di tampilan, bukan di server.

5. Chatbot dan agen yang terlalu percaya

Aplikasi dengan fitur AI menambah satu lapis risiko: instruksi pengguna bisa menggeser perilaku model (prompt injection), dan alat yang diberikan ke agen bisa dipanggil di luar niat pembuatnya. Prinsipnya: data rahasia jangan pernah berada dalam jangkauan prompt, dan setiap alat (tool) harus punya batas izin sendiri.

6. Dependensi yang tidak benar-benar ada

Model kadang menyarankan nama paket yang tidak ada — dan nama itu bisa didaftarkan orang lain. Memasangnya berarti menjalankan kode milik pihak tak dikenal. Pastikan setiap paket yang ditambahkan benar-benar Anda kenal, dan kunci versinya.

7. Satu kunci untuk semua lingkungan

Kunci pengembangan yang sama dipakai di produksi membuat satu kebocoran di tempat pengujian langsung membuka data asli. Pisahkan kredensial per lingkungan, dan rotasi kunci yang pernah terekspos — menghapusnya dari kode tidak membuatnya aman kembali.

Kenapa "sudah minta AI review" tidak menutup ini

Meninjau kode dengan AI berguna untuk gaya, struktur, dan logika. Tapi tiga hal di atas sering lolos karena bukan soal kode: izin yang longgar di layanan pihak ketiga, konfigurasi yang ikut terunggah, dan rahasia yang bocor lewat berkas yang tidak pernah dibaca ulang. Semuanya baru terlihat kalau ada yang memeriksa hasil akhir — kode yang benar-benar dikirim ke server dan permukaan yang benar-benar terbuka ke internet.

Cara menutupnya: enam langkah yang bisa dilakukan hari ini

1. Pindahkan semua panggilan rahasia ke server. Frontend hanya bicara dengan backend Anda sendiri. Tidak ada kunci pihak ketiga di browser.
2. Rotasi kunci yang pernah terekspos. Anggap sudah bocor. Buat kunci baru, cabut yang lama, baru bersihkan kode.
3. Nyalakan aturan akses di basis data. Tulis aturan per tabel, lalu uji dengan akun pengguna biasa: apakah ia bisa membaca data pengguna lain? Harusnya tidak.
4. Uji setiap endpoint tanpa token. Harus 401/403. Yang menjawab 200 tanpa sesi adalah temuan, bukan kebetulan.
5. Batasi alat yang diberikan ke agen AI. Satu alat = satu izin minimum. Jangan pernah memberi akses tulis ke seluruh basis data hanya karena lebih cepat.
6. Pisahkan lingkungan dan pin dependensi. Kunci berbeda untuk dev dan produksi, versi paket dikunci, dan daftar paket ditinjau sebelum rilis.

Urutan memeriksa: gratis dulu, baru yang berbayar

Sebelum menyewa siapa pun, ada dua pemeriksaan yang bisa Anda lakukan sendiri tanpa biaya:

1. Periksa permukaan publik. Free URL scan AISG memeriksa tujuh kelompok hal yang terlihat dari luar: TLS, header keamanan, CORS, jalur terbuka seperti .env, aset, rahasia yang tertulis di HTML/JS, dan konfigurasi email. Tanpa akun, tanpa instalasi.
2. Pindai kode secara lokal. Paket Community gratis menjalankan 3 sensor (SAST, secrets, data-layer) di mesin Anda — kode tidak keluar dari komputer. Ini yang menangkap kunci tertanam dan konfigurasi berbahaya yang tidak terlihat dari browser.

Setelah temuan ditutup, simpan laporannya. Bukan untuk pajangan, tapi karena bukti "sebelum dan sesudah" adalah satu-satunya cara membuktikan bahwa perbaikan benar-benar terjadi — berguna saat klien atau auditor bertanya.

Batas yang harus Anda tahu

Pemindaian otomatis — termasuk AISG — memberi indikasi, bukan bukti eksploitasi. Ia tidak menyusun rantai serangan untuk membuktikan dampak, dan temuannya tetap perlu divalidasi manusia. Untuk aplikasi yang memegang data pembayaran atau data pribadi dalam jumlah besar, pentest oleh manusia tetap diperlukan; artikel biaya pentest membahas kapan itu benar-benar perlu.

Kesimpulan

Vibe coding aman sejauh yang Anda periksa. Kecepatannya nyata, dan tidak perlu dibuang — yang perlu ditambahkan hanya satu langkah sebelum aplikasi dipakai orang lain: periksa hasil akhirnya dari dua sisi, kode yang Anda kirim dan permukaan yang terbuka.

Kalau Anda ingin mulai sekarang: buka free URL scan, masukkan alamat aplikasi Anda, dan lihat apa yang benar-benar terlihat dari internet. Hasilnya akan memberi tahu apakah ada yang perlu diperbaiki hari ini, bukan minggu depan.