Keamanan Kode Hasil AI: Apa yang Perlu Diwaspadai Vibe Coder

Foto oleh FlyD di Unsplash

Vibe coding sudah jadi cara paling populer buat mahasiswa dan pemula bikin aplikasi tanpa harus jago ngoding dulu. Tinggal ketik prompt, AI langsung nulis ratusan baris kode, dan dalam hitungan menit ada tampilan yang jalan di browser. Rasanya seperti sihir — tapi di balik kecepatan itu ada satu pertanyaan yang jarang ditanyakan: apakah kode yang dihasilkan AI ini aman? Jawabannya, berdasarkan riset-riset terbaru, cukup mengkhawatirkan. AI memang bisa nulis kode yang jalan, tapi "jalan" dan "aman" adalah dua hal yang sangat berbeda. Artikel ini membahas apa saja risiko keamanan yang paling sering muncul di kode hasil AI, kenapa LLM cenderung membuat kesalahan yang sama berulang-ulang, insiden nyata yang sudah terjadi, dan langkah-langkah praktis yang bisa kamu lakukan sebagai vibe coder — termasuk kalau kamu pakai AI app builder seperti Willow.

Seberapa Sering AI Menulis Kode yang Bocor Keamanannya?

Laporan 2025 GenAI Code Security Report dari Veracode menguji lebih dari 100 large language model pada 80 tugas coding nyata, dan hasilnya cukup mengejutkan: 45% dari kode yang dihasilkan AI mengandung celah keamanan yang masuk kategori OWASP Top 10. Angka ini bukan cuma soal bahasa pemrograman yang jarang dipakai — bahkan JavaScript dan Python, dua bahasa favorit vibe coder, punya tingkat kegagalan keamanan 38–45%. Java justru paling parah, sampai 70–72%. Yang lebih bikin was-was, kategori cross-site scripting (XSS) gagal diamankan pada 86% sampel kode yang relevan, dan log injection gagal pada 88% kasus. Artinya, kalau AI diminta menulis fitur yang rawan XSS, kemungkinan besar kode yang keluar justru rentan diserang. Temuan lain yang tak kalah penting: model AI generasi baru yang lebih pintar dan lebih besar ternyata tidak menunjukkan perbaikan berarti dalam hal keamanan dibanding model lama. Kemampuan fungsional AI terus naik dari waktu ke waktu, tapi keamanannya jalan di tempat — ini menunjukkan masalahnya bukan soal "AI belum cukup canggih", melainkan soal bagaimana model dilatih dan apa yang diprioritaskan saat menghasilkan kode.

Kenapa LLM Cenderung Membuat Kesalahan Keamanan yang Sama

CTO Veracode menjelaskan akar masalahnya dengan cukup jelas: pengguna AI coding tools "tidak perlu menyebutkan batasan keamanan untuk mendapatkan kode yang mereka inginkan, sehingga secara efektif menyerahkan keputusan soal keamanan kepada LLM" (dikutip dari Help Net Security). Ini persis pola vibe coding: kamu minta "buatkan form login" atau "buatkan endpoint untuk ambil data user", dan AI akan menulis versi paling sederhana yang membuat fitur itu berfungsi — tanpa validasi input, tanpa pengecekan otorisasi, tanpa enkripsi tambahan — kecuali kamu secara eksplisit memintanya. LLM dilatih dari jutaan baris kode publik di internet, termasuk banyak contoh kode tutorial atau kode lama yang memang tidak dirancang untuk produksi. Karena tujuannya adalah menghasilkan kode yang berfungsi dan mudah dipahami, model cenderung memilih jalan pintas yang paling umum ditemui di data latihnya — bukan jalan yang paling aman. Ditambah lagi, riset dari Snyk menemukan hal yang ironis: lebih dari 75% developer justru percaya kode hasil AI lebih aman dibanding kode buatan manusia, padahal 56,4% dari mereka sendiri sering menemukan masalah keamanan di kode AI itu. Rasa percaya diri yang salah tempat ini berbahaya, apalagi buat vibe coder pemula yang tidak punya latar belakang keamanan aplikasi untuk mengecek ulang hasil kerja AI.

Kelas Kerentanan yang Paling Sering Muncul

Dari berbagai riset, ada beberapa pola kerentanan yang berulang kali muncul di kode hasil AI. Pertama, broken access control — AI sering membuat backend yang "pasrah" memberikan semua data ke frontend, lalu berharap tampilan UI yang menyaring mana yang boleh dilihat user. Padahal penyerang bisa dengan mudah memanggil API itu langsung tanpa lewat UI sama sekali. Kedua, hardcoded secrets — API key, password database, atau token pihak ketiga ditulis langsung di dalam kode alih-alih disimpan di environment variable. Ketiga, SQL injection dan XSS karena input dari user langsung dipakai tanpa validasi atau sanitasi. Keempat, weak cryptography — AI kadang memilih algoritma enkripsi usang atau menyimpan password dalam bentuk yang mudah dibongkar. Semua pola ini punya kesamaan: mereka adalah jalan pintas yang membuat fitur "kelihatan" berfungsi di demo, tapi runtuh begitu ada orang yang mencoba mengeksploitasinya dengan sengaja.

Insiden Nyata: Ketika Aplikasi Vibe-Coded Bocor ke Publik

Ini bukan cuma teori. Sepanjang 2025 dan awal 2026, sudah banyak kasus nyata aplikasi hasil vibe coding yang kebobolan. Investigasi XDA Developers menemukan pola yang sama berulang kali di berbagai aplikasi: sebuah platform matchmaking game membocorkan seluruh database user — nama, email, rank — lewat satu endpoint API karena penyaringan data cuma dilakukan di sisi frontend, bukan di server. Peneliti yang menguji 1.645 aplikasi buatan platform AI builder Lovable menemukan sekitar 170 di antaranya (kira-kira 1 dari 10) bocor lewat celah yang persis sama: header otorisasi yang dihapus saja sudah cukup untuk membuka seluruh database pengguna. Ada juga kasus aplikasi verifikasi identitas yang membocorkan lebih dari 70.000 foto dan 13.000 dokumen KTP karena cloud storage-nya salah konfigurasi dan bisa dibaca siapa saja. Kasus paling besar yang jadi sorotan adalah insiden "Moltbook" pada Februari 2026, sebuah aplikasi sosial hasil vibe coding yang database-nya salah konfigurasi hingga mengekspos 1,5 juta token autentikasi dan 35.000 alamat email ke internet terbuka — AI yang membangunnya diam-diam membuat endpoint admin yang bisa diakses publik tanpa login sama sekali. Akar masalah dari hampir semua kasus ini sama persis: backend memercayai apa pun yang diminta client, dan tidak ada pengecekan otorisasi di sisi server.

Bukan Cuma Bocor Data — Secrets Sprawl Juga Naik Tajam

Masalah lain yang jarang disadari vibe coder adalah kebiasaan menaruh secret (API key, connection string database, token) langsung di kode alih-alih di environment variable. GitGuardian mencatat dalam laporan State of Secrets Sprawl 2026 bahwa ditemukan 28,65 juta secret baru yang ter-hardcode di commit publik GitHub sepanjang 2025 — lonjakan 34% dari tahun sebelumnya, dan merupakan kenaikan tahunan terbesar yang pernah tercatat. Kredensial layanan AI sendiri — API key untuk provider LLM, layanan embedding, platform AI — naik 81% year-over-year, mencapai lebih dari 1,27 juta kebocoran terdeteksi. Yang lebih relevan buat vibe coder: commit hasil AI-assisted punya tingkat kebocoran secret 3,2%, dibanding baseline 1,5% untuk commit publik secara umum — kira-kira dua kali lipat lebih berisiko. Ini masuk akal kalau dipikir: saat kamu minta AI "hubungkan ke database ini" atau "pakai API key ini untuk fitur cuaca", cara paling cepat bagi AI untuk membuat itu berfungsi adalah menempelkan nilai itu langsung di kode, bukan membuat referensi ke environment variable yang butuh setup tambahan.

Langkah Praktis buat Vibe Coder — Tanpa Harus Jadi Ahli Keamanan

Kabar baiknya, kamu tidak perlu jadi security engineer untuk mengurangi risiko ini secara signifikan. Beberapa kebiasaan dasar berikut sudah cukup menutup celah paling umum:

• Jangan pernah hardcode secret. Semua API key, password database, dan token pihak ketiga wajib disimpan di file environment variable (.env), bukan ditulis langsung di kode.
• Pastikan .env masuk .gitignore sebelum kamu push kode ke GitHub — sekali secret ter-commit ke riwayat git publik, anggap saja sudah bocor selamanya, bahkan setelah dihapus di commit berikutnya.
• Jangan percaya validasi yang cuma ada di frontend. Semua pengecekan input dan aturan bisnis penting harus divalidasi ulang di server/API, karena penyerang bisa langsung memanggil API tanpa lewat tampilan UI kamu sama sekali.
• Terapkan otorisasi di level data, bukan cuma di level tampilan. Kalau pakai database seperti Supabase atau Postgres, aktifkan row-level security supaya user A tidak bisa membaca data user B lewat endpoint yang sama.
• Uji coba dengan mematikan JavaScript atau panggil API langsung (lewat browser devtools atau Postman) untuk memastikan data sensitif memang tidak ikut terkirim ke client sebelum difilter.
• Minta AI menjelaskan logika otorisasinya. Tanyakan langsung: "siapa saja yang bisa mengakses endpoint ini, dan bagaimana cara membatasinya?" — ini memaksa AI (dan kamu) memikirkan ulang bagian yang biasanya dilewatkan.
• Selalu gunakan HTTPS dan hash password dengan algoritma yang benar (misalnya bcrypt/argon2), jangan simpan password dalam bentuk teks biasa atau enkripsi lemah.
• Batasi rate limit pada endpoint autentikasi supaya tidak mudah jadi sasaran brute force.
• Lakukan review manual sebelum deploy ke publik — minimal baca ulang bagian yang berhubungan dengan login, pembayaran, dan akses data pribadi, karena ini bagian yang paling sering jadi sasaran serangan.

Poin pentingnya: kesalahan-kesalahan ini bukan soal AI-nya "bodoh", tapi soal siapa yang bertanggung jawab mengisi kekosongan yang tidak diminta secara eksplisit. Semakin spesifik dan sadar keamanan prompt yang kamu tulis, semakin besar kemungkinan AI menghasilkan kode yang benar-benar aman — bukan cuma kelihatan berfungsi di demo.

Di Mana Posisi AI App Builder seperti Willow dalam Semua Ini?

Sebagai platform AI app builder yang dipakai banyak mahasiswa dan vibe coder di Indonesia, Willow (gowillow.id) memudahkan proses membangun aplikasi Next.js dari nol lewat percakapan dengan AI agent. Tapi penting untuk jujur di sini: tidak ada AI app builder — termasuk Willow — yang secara otomatis menjamin kode yang dihasilkan 100% aman. Riset-riset di atas menunjukkan bahwa risiko keamanan kode AI adalah masalah level industri, bukan masalah satu tools tertentu. Yang bisa dilakukan platform seperti Willow adalah memudahkan kamu menerapkan praktik dasar — misalnya menyimpan environment variable dengan benar, memisahkan struktur project yang rapi, dan memberi ruang untuk kamu meninjau ulang kode yang dihasilkan sebelum di-deploy. Tapi kewaspadaan tetap ada di tangan kamu sebagai pembuat aplikasi. Kalau kamu sedang belajar no-code atau AI app builder di Indonesia, anggap keamanan aplikasi sebagai bagian dari proses belajar itu sendiri, bukan langkah opsional yang bisa dilewati karena "yang penting jalan".

Vibe coding membuka pintu bagi jutaan orang — termasuk mahasiswa tanpa latar belakang computer science — untuk membangun produk digital sendiri, dan itu hal yang luar biasa. Tapi kecepatan itu punya harga: kalau kamu tidak sadar risiko keamanan kode hasil AI, aplikasi yang kamu banggakan bisa jadi pintu masuk kebocoran data penggunamu sendiri. Kabar baiknya, sebagian besar celah yang disebutkan di atas bisa ditutup dengan kebiasaan sederhana — bukan gelar sarjana keamanan siber. Mulai dari hal kecil: jangan hardcode secret, validasi ulang di server, dan selalu bertanya "siapa yang seharusnya tidak boleh melihat ini?" sebelum kamu klik deploy.