Aplikasi Buatan AI Aman atau Tidak? Cara Mengecek Sebelum Dipakai Pelanggan

Aplikasi yang dibangun lewat prompt ke AI hampir selalu berhasil jalan, tapi keamanannya tidak ikut jadi otomatis. Dua riset yang terbit tahun 2026 menemukan sekitar 44% kode buatan AI mengandung celah keamanan, dan 98% aplikasi hasil vibe coding yang dipindai punya minimal satu celah. Yang paling sering terjadi: basis datanya bisa dibaca atau dihapus tanpa login sama sekali. Sebelum aplikasi seperti itu kamu pakai untuk menampung data pelanggan, ada empat hal yang perlu dicek — dan semuanya bisa kamu cek sendiri dalam waktu kurang dari satu jam.

Vibe coding — istilah untuk membuat aplikasi dengan cara mengetik keinginanmu ke AI, lalu AI yang menulis kodenya — sekarang jadi jalan pintas favorit. Untuk prototipe, itu bagus. Masalahnya muncul saat prototipe itu diam-diam naik jadi aplikasi produksi yang dipakai pelanggan beneran, tanpa ada yang pernah membuka bagian belakangnya.

Kami di Tiga Awan makin sering dipanggil untuk situasi yang sama: klien punya aplikasi internal atau form pendaftaran buatan AI, tampilannya rapi, alurnya jalan, tapi tidak ada yang tahu apakah datanya aman. Artikel ini isinya persis apa yang kami cek saat menerima kasus seperti itu.

Kenapa aplikasi buatan AI bisa jalan tapi tetap bocor?

Karena "jalan" dan "aman" diuji oleh hal yang berbeda, dan cuma satu di antaranya yang kelihatan dari layar.

Menurut 2026 GenAI Code Security Report dari Veracode yang terbit 28 Juli 2026, model AI sekarang menghasilkan kode yang secara sintaks benar hampir 100% kali. Tapi rata-rata tingkat kelulusan uji keamanannya cuma 56% — nyaris tidak berubah dari 55% di laporan pertama mereka. Artinya sekitar 44% tugas menulis kode menghasilkan celah keamanan yang bisa dipakai orang lain.

Angka itu tidak membaik meski modelnya makin canggih. Veracode mencatat model yang khusus dilatih untuk coding rata-rata 51%, sementara model umum 52%. Model besar 53%, model kecil 51%. Model terbaik dalam pengujian mereka ada di 68% — tetap gagal di hampir satu dari tiga tugas keamanan.

Yang lebih berguna untuk kamu: kegagalannya tidak merata. Untuk celah jenis SQL injection, model lulus 83%. Untuk kriptografi, 87%. Tapi untuk cross-site scripting cuma 15%, dan log injection 12%. Jenis celah yang butuh pemahaman konteks — data masuk dari mana, dipakai di mana — justru yang paling sering lolos.

Seberapa parah kondisinya di aplikasi yang sudah tayang?

Ada satu pemindaian besar yang menjawab ini dengan angka, bukan perasaan.

Pada Juni 2026, Symbiotic Security menerbitkan hasil pemindaian 1.072 aplikasi hasil vibe coding yang memakai Supabase sebagai basis data. Aplikasi-aplikasi ini dibuat lewat Lovable, v0, Bolt.new, Replit, Windsurf, dan sejenisnya. Hasilnya:

Temuan	Jumlah	Porsi
Aplikasi dengan minimal satu celah	1.046 dari 1.072	98%
Aplikasi dengan celah tingkat kritis	173 dari 1.072	16%
Aplikasi yang bersih sepenuhnya	26 dari 1.072	2%
Data bisa dihapus tanpa login	172 aplikasi	—
Data bisa diubah tanpa login	172 aplikasi	—
Seluruh isi tabel bisa dibaca tanpa login	39 aplikasi	—
Kolom sensitif (email, token, nomor HP) terbuka	34 aplikasi	—

Rata-rata 5,9 celah per aplikasi. Satu aplikasi terburuk punya 30 celah, empat di antaranya kritis.

Tabel yang paling sering ditemukan terbuka juga bikin nyesek kalau dibaca sebagai pemilik bisnis: leads, profiles, contact_submissions, admin_users, payments, chat_messages. Itu bukan tabel eksperimen. Itu data prospek, data pelanggan, dan akun admin.

Ini bukan kasus satu-dua platform nakal. Ini pola. Bahkan sudah ada nomor resminya: CVE-2025-48757, diterbitkan ke basis data NVD pada 30 Mei 2025, mencatat bahwa kebijakan Row-Level Security yang kurang di aplikasi hasil Lovable memungkinkan penyerang tanpa akun membaca atau menulis ke tabel mana pun. Vendornya sendiri membantah klasifikasi itu dengan alasan pelanggan yang bertanggung jawab atas data aplikasinya. Terlepas dari siapa yang benar, kesimpulan praktisnya sama: tidak ada yang memasang pengamannya untukmu.

Apa akar masalahnya dalam bahasa sehari-hari?

Bayangkan aplikasi kamu sebagai toko dengan gudang di belakang.

Cara kerja platform-platform ini: aplikasi di HP atau browser pelanggan bicara langsung ke gudang, memakai satu kunci yang memang sengaja dibuat publik. Kunci itu tertanam di dalam halaman, jadi siapa pun yang membuka halamanmu bisa melihatnya. Itu bukan kebocoran — memang begitu desainnya.

Pengamannya bukan kunci itu, melainkan aturan per-rak di dalam gudang: rak mana boleh dilihat siapa. Di Supabase namanya Row Level Security. Kalau aturan itu tidak dipasang, kunci publik tadi bisa dipakai membuka seluruh gudang.

Dan AI penulis kode biasanya tidak memasangnya, karena aturan itu tidak dibutuhkan supaya aplikasi terlihat jalan. Aplikasi tanpa aturan rak justru jalan lebih mulus saat diuji — tidak ada yang menolak permintaan. Bugnya baru terasa kalau ada yang iseng mengetuk pintu gudang.

Bagaimana cara mengecek aplikasimu sendiri?

Lima langkah ini bisa kamu kerjakan sendiri dengan akses yang memang kamu punya sebagai pemilik. Tidak perlu jadi programmer.

1. Buka dasbor basis datamu dan lihat status RLS per tabel. Di Supabase, daftar tabel punya penanda apakah Row Level Security aktif. Cari tabel yang berisi data orang — pendaftaran, kontak, pesanan, pesan. Kalau ada satu saja yang mati, hentikan dulu penggunaan aplikasinya untuk data asli sampai dibetulkan.
2. Cek tabel mana yang punya kebijakan, bukan cuma tombol menyala. RLS aktif tapi tanpa kebijakan sama sekali artinya semua ditolak, dan aplikasimu akan error. RLS aktif dengan kebijakan "izinkan semua" artinya sama saja mati. Baca isi kebijakannya, jangan cuma statusnya.
3. Daftar semua kunci pihak ketiga yang dipakai aplikasi itu. Pembayaran, pengirim email, WhatsApp, layanan AI. Riset Symbiotic menemukan 24 situs punya kunci API pihak ketiga tertulis di kode yang bisa dibaca publik. Kalau ada yang seperti itu, kunci lama harus dicabut dan diganti, bukan cuma disembunyikan.
4. Matikan pendaftaran akun yang terbuka kalau memang tidak dipakai. Di pemindaian itu, 220 situs punya endpoint pendaftaran terbuka dan 69 situs mematikan konfirmasi email. Artinya siapa pun bisa membuat akun dengan email palsu. Untuk aplikasi internal, ini seharusnya ditutup sejak awal.
5. Uji dari sisi pengguna biasa, bukan dari akunmu sendiri. Buat satu akun pelanggan uji coba, lalu coba akses data milik akun uji coba lain. Kalau kelihatan, kebijakannya salah. Ini uji paling murah dan paling sering dilewat.

Kalau salah satu langkah di atas menemukan masalah, jangan buru-buru membangun ulang semuanya. Sebagian besar kasus yang kami tangani selesai di tingkat konfigurasi, bukan tulis ulang kode.

Mana yang layak dibangun dengan AI dan mana yang tidak?

Cara paling waras memutuskannya bukan lewat jenis aplikasinya, tapi lewat jenis data yang masuk ke dalamnya.

Isi aplikasi	Contoh	Layak dibangun cepat dengan AI?
Tidak ada data orang	Kalkulator harga, katalog statis, demo tampilan	Ya, aman
Data internal tim, tidak sensitif	Pencatat stok, papan tugas, arsip link	Ya, dengan RLS dipasang
Data prospek dan kontak	Form pendaftaran, daftar leads, survei	Boleh, tapi wajib diaudit sebelum tayang
Akun pelanggan dan login	Portal member, dasbor klien	Jangan tanpa peninjau yang paham
Transaksi dan pembayaran	Checkout, invoice, langganan	Tidak. Pakai penyedia pembayaran mapan
Data pribadi bersifat khusus	Rekam medis, data anak, data keuangan pribadi	Tidak

Patokan sederhananya: kalau kebocoran data di aplikasi itu akan memaksamu menelepon pelanggan satu per satu untuk minta maaf, aplikasi itu tidak boleh tayang tanpa ditinjau orang. Pertimbangan serupa soal data apa yang aman diserahkan ke layanan AI kami bahas terpisah di data yang tidak boleh dimasukkan ke ChatGPT dan AI lain.

Apa yang biasanya jadi masalah saat kami menerima aplikasi seperti ini?

Tiga hal, dan hampir selalu urutannya sama.

Pertama, tidak ada yang tahu siapa pemilik akunnya. Aplikasi dibuat pakai akun pribadi karyawan yang sudah resign, atau akun trial yang tagihannya tidak jelas ke mana. Sebelum bicara keamanan, kepemilikan akun harus beres dulu. Ini pola yang sama seperti urusan domain dan hosting yang kami uraikan di brief yang perlu disiapkan sebelum minta penawaran.

Kedua, tidak ada salinan. Kode ada di dalam platform, basis data ada di layanan lain, dan tidak ada backup yang pernah diuji. Kalau akun platformnya bermasalah, aplikasinya hilang beserta datanya.

Ketiga, tidak ada yang merawat. Aplikasi buatan AI tidak bebas perawatan — dependensinya tetap usang, kunci tetap perlu dirotasi, dan platformnya tetap berubah. Pos biaya berjalan yang sering luput ini mirip dengan yang kami rinci untuk situs biasa di biaya maintenance website per tahun.

Batasan artikel ini dan angka yang tidak bisa kami pastikan

Beberapa catatan supaya kamu tidak salah pakai isinya.

Dua riset yang dikutip di sini punya cakupan spesifik. Veracode menguji model dalam kondisi laboratorium dengan tugas coding yang dirancang, bukan aplikasi nyata. Symbiotic memindai aplikasi yang memakai Supabase dan bisa ditemukan mesin pencari — aplikasi yang tidak terindeks tidak masuk hitungan, jadi angka 98% berlaku untuk sampel itu, bukan untuk semua aplikasi vibe coding di dunia.

Ada juga angka yang beredar luas soal jumlah startup yang harus membangun ulang aplikasinya beserta biayanya dalam dolar. Kami tidak memakainya di sini karena tidak menemukan sumber primer yang bisa diverifikasi hari ini. Kalau kamu menemukan angka semacam itu di artikel lain, cek dulu sumbernya sebelum dipakai untuk mengambil keputusan.

Terakhir, kondisi platform berubah cepat. Beberapa platform sudah menambahkan peringatan RLS dan pemindai keamanan bawaan sejak kasus 2025. Yang tertulis di sini adalah kondisi per Agustus 2026; cek dokumentasi platform yang kamu pakai untuk status terbarunya.

Pertanyaan yang sering muncul

Apakah vibe coding selalu berbahaya?

Tidak. Yang berbahaya adalah memakai hasilnya untuk data asli tanpa pernah membuka bagian belakangnya. Untuk prototipe, demo ke klien, atau alat internal tanpa data orang, vibe coding justru pilihan yang masuk akal karena jauh lebih murah dan cepat.

Kalau saya pakai model AI yang lebih pintar, apakah kodenya jadi lebih aman?

Sedikit membantu, tapi tidak menyelesaikan. Data Veracode menunjukkan model terbaik dalam pengujian mereka ada di 68% dan model rata-rata di 51–53%. Selisihnya nyata, tapi bahkan yang terbaik masih gagal di sekitar sepertiga tugas keamanan. Memilih model lebih baik mengurangi beban perbaikan, bukan menghapus kebutuhan pemeriksaan.

Bisa tidak saya minta AI-nya sendiri untuk mengaudit keamanannya?

Bisa dipakai sebagai lapisan pertama untuk menangkap hal-hal jelas, tapi jangan dijadikan satu-satunya. AI yang menulis kodenya cenderung tidak melihat asumsi yang sama yang bikin dia salah sejak awal. Untuk aplikasi yang menampung data pelanggan, tetap perlu ada orang yang mengecek dari luar.

Aplikasi saya cuma dipakai internal, apakah tetap perlu dicek?

Perlu, kalau ia bisa diakses dari internet. Aplikasi yang tayang di alamat publik bisa ditemukan mesin pencari — dan itu persis cara riset Symbiotic menemukan 58% sampelnya. "Cuma tim yang tahu alamatnya" bukan pengaman.

Kalau ternyata aplikasi saya bocor, apa yang pertama dilakukan?

Matikan akses publiknya dulu, lalu rotasi semua kunci dan token yang dipakai aplikasi itu. Setelah itu baru cek log untuk melihat apakah ada akses yang tidak wajar. Urutannya penting: memperbaiki kebijakan sementara kunci lama masih berlaku tidak menutup pintu yang sudah terbuka.

Lebih baik saya bangun ulang saja pakai cara biasa?

Belum tentu, dan jangan diputuskan sebelum tahu masalahnya apa. Banyak kasus selesai dengan memasang kebijakan akses yang benar dan merapikan kunci — jauh lebih murah daripada tulis ulang. Pertimbangan memilih fondasi untuk jangka panjang kami bahas di WordPress atau website custom.

Langkah berikutnya

Kalau kamu punya aplikasi atau form buatan AI yang sudah menampung data pelanggan dan belum pernah dicek, kirim alamatnya lewat audit gratis. Kami cek status kebijakan aksesnya, kunci yang terekspos, dan header keamanannya, lalu bilang apa adanya: mana yang cukup dibetulkan konfigurasinya, mana yang memang perlu dibangun ulang, dan kalau ternyata aman, kami bilang aman.