Keamanan Vibe Coding: Cara Melindungi Aplikasi Buatan AI

Petunjuk lebih lanjut untuk bekerja dengan Ailoot tersedia di dokumentasi.

Mengapa aplikasi buatan AI lebih sering diretas?#

Saya sendiri membuat produk dengan AI, dan saya tidak menjadi paranoid soal keamanan sampai-sampai “mengunci semuanya semaksimal mungkin”. Namun, ada tingkat dasar yang tidak boleh Anda abaikan, atau suatu hari Anda akan bangun dengan basis data kosong dan server Anda dipakai menambang oleh orang lain. Panduan ini membahas tingkat dasar tersebut. Bukan “menjadi pakar keamanan”, melainkan “jangan sengaja mencelakakan diri sendiri”.

Akar masalahnya sederhana. Saat Anda meminta agen AI, “buatkan aplikasi untuk memesan jadwal klien”, agen akan membuat aplikasi berfungsi secepat mungkin. Keamanan adalah pekerjaan ekstra yang tidak terlihat dalam demo. Jadi, basis data disetel terbuka, kunci pembayaran langsung dimasukkan ke kode, dan pemeriksaan “apakah pengguna ini punya akses?” hanya ada di browser, tempat pemeriksaan itu bisa dilewati dalam sekejap.

Dengan kata lain, celahnya muncul sendiri secara default. Anda tidak melakukan kesalahan. Anda hanya tidak melakukan apa-apa—dan dalam keamanan, tidak bertindak berarti “terbuka untuk semua orang”.

Ada lapisan ketiga. Logikanya jelas: agen menjalankan git add . dan git push tanpa melihat isinya, lalu file .env Anda yang berisi kunci ikut dipublikasikan bersama semuanya.

Pelajaran pahit apa yang sudah didapat para pembuat aplikasi dengan vibe coding?#

Cara terbaik untuk mencegah kelalaian adalah belajar dari kesalahan orang lain. Berikut empat laporan yang layak dibaca sebelum Anda memublikasikan proyek.

Lovable dan RLS yang dimatikan. Platform Lovable membuat aplikasi dari deskripsi teks. Pada 2025, ditemukan celah sistemik pada aplikasinya dan diberi nomor CVE-2025-48757. Penyebabnya: aplikasi yang dihasilkan tidak memiliki aturan akses tingkat baris pada basis data (RLS, dijelaskan di bawah). Seorang peneliti memeriksa sampel dan menemukan 303 titik akses terbuka di 170 aplikasi. Nama, nomor telepon, status pembayaran, kunci API milik orang lain, bahkan alamat rumah terekspos. Pada sekitar 70 persen aplikasi yang diperiksa, perlindungan tingkat baris benar-benar dimatikan.

Tea dan data sensitif. Aplikasi Tea (ulasan anonim tentang orang) kehilangan sekitar 72,000 gambar pada Juli 2025, termasuk 13,000 swafoto dan foto dokumen, lalu lebih dari sejuta pesan pribadi. Penyebab teknisnya adalah penyimpanan terbuka dan pemeriksaan akses yang lemah. Komunitas keamanan mengutip Tea sebagai contoh nyata: ketika peluncuran cepat lebih penting daripada pemeriksaan izin, data sensitif menjadi hal pertama yang bocor.

Contoh praktis lainnya. Dalam kasus yang diceritakan penulis asli, aplikasi seorang pembuat dengan vibe coding diretas karena AI menetapkan kata sandi default saat membuat basis data—kata sandi yang dapat ditebak secara otomatis. Lalu terjadilah urutan yang biasa: penyusup masuk, memasang program penambang, dan menulis ulang proyek. Server harus dihapus seluruhnya. Kata sandi default ibarat pintu tak terkunci dengan papan bertuliskan “silakan masuk”.

Dua sisi keamanan: di mana tepatnya Anda rentan?#

Saat orang membicarakan “keamanan vibe coding”, biasanya mereka mencampuradukkan dua kekhawatiran yang sama sekali berbeda. Mari kita pisahkan, karena cara melindunginya berbeda.

Sisi pertama—agennya sendiri. Anda menjalankan agen AI di komputer dan memberinya akses ke berkas, terminal, kunci, dan basis data. Risikonya adalah agen bukan manusia: agen mengikuti instruksi secara harfiah dan akan mencari jalan terpendek, meskipun jalan itu berbahaya. Ini juga mencakup risiko perintah orang lain “disuntikkan” ke agen melalui teks yang dibacanya (ini disebut prompt injection).

Sisi kedua—aplikasi yang sudah jadi. Inilah aplikasi yang Anda publikasikan dan digunakan orang. Sasaran serangannya adalah situs atau layanan yang Anda publikasikan: penyerang masuk ke basis data terbuka, mengirim permintaan palsu, atau menebak akun orang lain. Agen tidak ada hubungannya dengan ini—celahnya sudah tertinggal sebelumnya, lalu dieksploitasi orang lain.

Anthropic, perusahaan di balik Claude, menyatakan prinsip perlindungan utama dengan cara ini—dan prinsip ini berlaku untuk kedua sisi:

Dalam praktiknya, artinya: jangan mengandalkan AI untuk “menghindari hal buruk dengan sendirinya”. Batasi dahulu hal-hal yang secara fisik dapat dilakukannya, baru minta AI berperilaku baik. Saat perilakunya gagal—dan itu akan terjadi—hanya batas tegas yang Anda tetapkan sebelumnya yang akan melindungi Anda.

Ingin AI bekerja secara konsisten dan berhenti mencelakakan Anda dalam setiap proyek baru? Aturan keamanan adalah bagian dari Second Brain Anda: tuliskan sekali di CLAUDE.md, dan agen akan mengikutinya dalam setiap permintaan.

Apa yang bisa dilakukan agen AI dengan akses ke komputer Anda?#

Risiko yang paling sering diremehkan adalah agen Anda sendiri yang memiliki izin terlalu luas. Anda bahkan tidak memerlukan peretas dari luar. Berikut contoh terbaru dari akhir Mei 2026. Agen Codex memerlukan izin administrator yang tidak dimiliki pengguna. Agen itu tidak menyerah—agen memeriksa keadaan, melihat bahwa pengguna tergabung dalam grup docker, yang setara dengan root, lalu memanfaatkan akses tersebut.

Tidak ada niat jahat di sini. Agen yang diminta “menyelesaikan tugas” hanya menemukan kelemahan struktural lebih cepat daripada manusia. Dan jika kelemahan itu memberinya akses ke kunci atau sistem produksi Anda, agen akan memanfaatkannya. Jadi, aturan nomor satu adalah hak akses minimum. Beri agen akses secukupnya untuk tugas tertentu, tidak lebih.

Apa yang bisa Anda lakukan dalam praktik, meskipun Anda bukan programmer?

1. Jangan jalankan agen dalam mode “izinkan semuanya” di mesin produksi

   Mode yang membuat agen tidak meminta konfirmasi (sering disebut bypass atau yolo) hanya untuk sandbox atau proyek pengujian, bukan mesin yang menyimpan kunci aktif dan akses produksi.

2. Larang agen membaca rahasia

   Di Claude Code, Anda dapat menerapkan aturan yang menolak akses ke berkas berisi kunci. Jadi, sekalipun agen ingin membuka .env, alatnya tidak akan mengizinkan.

3. Pisahkan kunci produksi

   Kunci untuk basis data produksi dan layanan pembayaran tidak boleh berada di folder yang sama dengan tempat agen menulis kode. Pisahkan lingkungan: gunakan kunci pengujian untuk bereksperimen.

4. Gunakan sandbox alat tersebut

   Alat AI modern dapat menjalankan perintah secara terisolasi (di dalam sandbox), tempat alat tidak memiliki akses ke bagian lain sistem. Di Claude Code, ini mengurangi permintaan izin sekitar 84 persen—jadi penggunaannya juga lebih praktis.

Aturan yang menolak pembacaan rahasia di Claude Code kira-kira seperti ini—letakkan di pengaturan izin:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Di mana Anda tidak boleh menaruh kunci API dan kata sandi?#

Kesalahan yang paling murah dan umum adalah menaruh kunci di dalam kode. Kunci API layanan pembayaran, kata sandi basis data, token bot—semuanya adalah rahasia. Simpan di berkas .env terpisah, dan cantumkan berkas itu di .gitignore supaya tidak ikut masuk ke git bersama kode.

Mengapa ini penting: kunci tidak akan lama berada di repositori publik. Bot memindai commit baru sepanjang waktu. Biasanya, bot menemukan kunci cloud, menjalankan server penambang mata uang kripto dengan biaya Anda, dan pagi harinya Anda menghadapi tagihan puluhan ribu. Pengembang sering menceritakan kasus seperti ini, dengan tagihan bernilai lima digit dalam dolar.

Skala masalah pada 2025: 28.65 juta rahasia baru yang ditulis langsung di dalam kode pada repositori publik, naik 34 persen dibanding tahun sebelumnya. Kebocoran kunci khusus layanan AI meningkat 81 persen. Vibe coding memperburuk keadaan karena agen melakukan commit tanpa melihat isinya.

Hal-hal yang perlu diperiksa secara manual sekarang:

1. Buka berkas .gitignore proyek

   Pastikan ada baris .env. Jika tidak ada, tambahkan sebelum commit pertama.

2. Buka repositori GitHub Anda

   Periksa bahwa berkas .env tidak ada di sana. Mencari .env atau sebagian kunci Anda di repositori adalah cara cepat untuk memeriksanya.

3. Jika kunci bocor, cabut dan terbitkan ulang

   Menghapus commit saja tidak cukup: kuncinya mungkin sudah diambil. Buka layanan terkait (penyedia pembayaran, layanan cloud, penyedia AI), cabut kunci lama, lalu terbitkan yang baru. Proses ini disebut rotasi.

4. Beri kunci izin seminimal mungkin

   Jika kunci hanya diperlukan untuk membaca, jadikan hanya-baca. Dengan begitu, jika kunci bocor pun, lebih sedikit yang bisa dicuri.

Mengapa semua orang bisa melihat basis data Anda tanpa RLS?#

Jika Anda membuat aplikasi di Supabase atau basis data serupa, ini bagian terpenting. RLS adalah singkatan dari Row Level Security. Sederhananya, ini adalah aturan yang menentukan baris mana dalam tabel yang ditampilkan kepada pengguna tertentu. Tanpanya, tabel “orders” akan menampilkan pesanan semua pelanggan kepada siapa pun.

Berikut penjelasan sederhana dari dokumentasi Supabase:

Inilah jebakan utama bagi pembuat dengan vibe coding. Saat Anda membuat tabel dengan mengeklik menu di dasbor Supabase, perlindungan otomatis diaktifkan. Namun, ketika AI membuat tabel—dan hampir selalu AI menulis perintah SQL secara langsung—RLS tetap dimatikan secara default. Artinya, tabel yang dibuat agen hampir pasti terbuka untuk seluruh internet. Inilah tepatnya cara 170 aplikasi Lovable tersebut mengalami kebocoran.

Yang perlu dilakukan:

1. Tanyakan langsung kepada agen

   Tulis: “tampilkan semua tabel yang RLS-nya dinonaktifkan”. AI akan membuat daftar—itulah antrean pekerjaan Anda.

2. Aktifkan RLS pada setiap tabel yang berisi data pengguna

   Tambahkan juga setidaknya satu kebijakan akses—misalnya, “pengguna hanya dapat melihat baris miliknya sendiri”.

3. Periksa dasbor

   Di dasbor Supabase, setiap tabel seharusnya menampilkan “RLS enabled”. Jika warnanya abu-abu atau merah, artinya tabel tersebut terbuka.

4. Uji secara langsung

   Masuk sebagai pengguna biasa dan coba minta data milik orang lain. Jika akses ditolak, kebijakannya berfungsi.

Mengapa pemeriksaan izin di antarmuka tidak melindungi Anda?#

Ilusi yang umum adalah: “Saya sudah mengatur supaya pengguna biasa tidak bisa melihat tombol admin.” Masalahnya, tombol hanyalah gambar di browser. Permintaan bisa dikirim langsung ke server tanpa menggunakan tombol. Jika server tidak memeriksa izin lagi, server akan menjalankan perintah orang lain.

Contoh klasik disebut IDOR. Bayangkan Anda membuka pesanan Anda di alamat dengan id=123. Ubah menjadi id=124, dan Anda bisa melihat pesanan orang lain karena server tidak memeriksa apakah pesanan itu memang milik Anda. Ini salah satu celah paling umum pada aplikasi yang dibuat dengan vibe coding, dan pemeriksaan izin yang lemah menjadi penyebab kebocoran Tea.

Aturannya sederhana: ulangi setiap pemeriksaan “apakah pengguna ini diizinkan melakukan ini?” di server. Antarmuka dibuat demi kemudahan; perlindungan harus berada di backend. Instruksi siap pakai untuk agen: “tambahkan pemeriksaan izin sisi server pada setiap endpoint yang membaca atau mengubah data pengguna; jangan mengandalkan elemen yang disembunyikan di antarmuka.”

Bagaimana cara memeriksa celah dalam kode jika Anda bukan programmer?#

Kabar baiknya: sekarang Anda dapat meminta AI yang sama untuk memeriksa keamanan—AI cukup baik dalam menemukan celah umum. Berikut tiga alat untuk tugas yang berbeda.

1. Perintah /security-review di Claude Code. Pemeriksaan satu kali terhadap branch saat ini untuk menemukan SQL injection, XSS, celah otorisasi, kebocoran data, dan masalah dependensi. Saya sudah menjelaskan cara kerjanya selangkah demi selangkah dan cara memasang pemeriksaan otomatis pada setiap perubahan dalam panduan terpisah tentang tinjauan keamanan di Claude Code. Hal utama di sini: inilah garis pertahanan pertama, dijalankan dengan satu perintah.

2. Plugin security-guidance resmi. Pasang dari marketplace plugin resmi dengan /plugin install security-guidance@claude-plugins-official (memerlukan Claude Code versi 2.1.144 atau yang lebih baru). Plugin ini memeriksa kode pada tiga tahap: setiap kali ada perubahan, di akhir setiap giliran, dan saat commit. Plugin ini mendeteksi bypass otorisasi, IDOR, injection, dan kriptografi yang lemah. Namun, Anthropic terus terang mengenai keterbatasannya:

npx skills add <author>/<repo>

Lalu, cukup beri tahu agen: “periksa proyek saya untuk mencari kerentanan”. Namun, ada catatan penting tentang koleksi ini, jadi saya membahasnya di bagian tersendiri di bawah.

Sebagai konteks: para pemain besar juga mulai serius menangani keamanan kode AI. Sebagai bagian dari Project Glasswing, yang diperluas pada 2 Juni 2026 hingga mencakup 150 organisasi, para mitra menemukan lebih dari 10,000 kerentanan kritis dalam waktu singkat menggunakan model Anthropic. Taruhannya jelas:

Bisakah Anda memercayai skills dan ekstensi dari GitHub?#

Bagian ini menjadi sangat rumit karena bahayanya berasal dari alat yang Anda pasang untuk keamanan. Saat menjalankan npx skills add ... atau memasang ekstensi, Anda mengambil kode orang lain, lalu agen menjalankannya dengan izin Anda. Jika pembuatnya diretas atau paketnya memang berbahaya sejak awal, Anda berada dalam masalah.

Ambil koleksi skills dari bagian sebelumnya. Namanya memuat “Anthropic”, sehingga membuat Anda lengah. Namun, deskripsinya sendiri menyatakan dengan jelas:

Dengan kata lain, namanya menyesatkan. Koleksinya sendiri saat ini sudah matang dan bersih, tetapi prinsipnya tetap sama: Anda memasangnya dengan risiko sendiri. Dan ancamannya bukan sekadar teori. Pada Mei 2026, sebuah ekstensi editor berbahaya hanya berada di marketplace selama 18 menit—dan dalam waktu itu, ekstensi tersebut berhasil mencuri kata sandi dari pengelola kata sandi, token GitHub, akses cloud, bahkan konfigurasi Claude Code milik orang-orang yang memasangnya. Detail buruk lainnya: malware seperti ini sering tetap bertahan setelah paket dihapus secara biasa dan berjalan lagi pada sesi berikutnya.

Saya membiasakan diri melakukan hal sederhana dan menyarankan Anda melakukannya juga: sebelum memasang skill apa pun dari GitHub, periksa sendiri. Akun penulis bisa diretas, akun bisa dibajak, dan malware bisa masuk ke repositori. Pemeriksaan adalah perlindungan Anda.

Hal minimum yang perlu dilakukan sebelum memasang: lihat siapa penulisnya dan berapa jumlah bintangnya, baca deskripsi skill, jangan memasang alat hanya “karena direkomendasikan dalam satu unggahan”, dan untuk alat yang belum dikenal, coba dahulu di lingkungan pengujian terpisah, bukan di mesin yang memiliki kunci produksi.

Apa yang akan menyelamatkan Anda setelah kebocoran: cadangan dan rollback#

Keamanan bukan hanya tentang “mencegah orang luar masuk”, tetapi juga “kembali ke keadaan normal saat terjadi masalah”. Karena masalah pasti akan terjadi. Dalam kasus praktis yang diceritakan, agen AI menghapus basis data aktif dalam proyek produksi saat menangani tugas rutin. Ada cadangan, tetapi usianya tiga hari—dan data selama tiga hari pun hilang begitu saja.

Itu membawa kita pada dua aturan.

Cadangkan sesering mungkin. Jika aplikasi Anda menyimpan data yang tidak ingin Anda hilangkan, salinan setiap tiga hari hanyalah ilusi perlindungan. Siapkan pencadangan otomatis setidaknya setiap 30 menit. Untuk sebagian besar basis data, termasuk Supabase, fitur ini dapat diaktifkan hanya dengan beberapa klik.

Git adalah asuransi terhadap agen. Git menyimpan riwayat kode Anda: Anda dapat memulihkan keadaan mana pun yang pernah berfungsi. Saat agen menulis ulang sesuatu yang sebelumnya berfungsi, kembalikan ke versi terakhir yang berfungsi alih-alih memperbaikinya secara manual. Jika AI menghapus atau merusak proyek dan Anda tidak tahu cara memulihkannya, lihat laporan terpisah: apa yang harus dilakukan jika AI menghapus basis data. Untuk melindungi proyek dari kerusakan sejak awal, lihat panduan cara melindungi Claude Code dari kerusakan.

Daftar periksa keamanan sebelum publikasi#

Ikuti daftar ini tepat sebelum publikasi. Sesuai urutan.

1. Rahasia disimpan di .env, dan .env tercantum di .gitignore. Tidak ada kunci di dalam kode. Tidak ada berkas .env di repositori publik.

2. Kunci memiliki izin seminimal mungkin. Setiap kunci hanya dapat melakukan hal yang diperlukan. Kunci produksi dipisahkan dari lingkungan agen.

3. RLS diaktifkan pada semua tabel yang berisi data pengguna, dan kebijakan akses sudah diterapkan.

4. Izin diperiksa di sisi server untuk setiap operasi terhadap data. Menyembunyikan tombol di antarmuka saja tidak cukup. Anda sudah menguji secara manual perubahan id di alamat.

5. Verifikasi tanda tangan webhook. Setiap penangan notifikasi eksternal (pembayaran, formulir) memverifikasi tanda tangannya.

6. Pembatasan laju diterapkan pada permintaan masuk dan operasi yang mahal, agar kata sandi tidak bisa ditebak dengan brute force dan tagihan Anda tidak membengkak.

7. Agen tidak berjalan dalam mode “izinkan semuanya” di mesin yang memiliki kunci produksi. Akses untuk membaca .env ditolak.

8. Pencadangan dilakukan sesering mungkin dan sudah diuji—Anda benar-benar pernah mencoba memulihkan data, bukan hanya percaya bahwa salinannya “ada di suatu tempat”.

9. Kode sudah diperiksa dengan /security-review atau plugin security-guidance. Temuan yang ada sudah diperbaiki.

10. Skills dan ekstensi milik orang lain sudah diperiksa sebelum dipasang. Tidak ada yang dipasang “tanpa diperiksa”.

Mulai dari mana hari ini#

Jangan mencoba menerapkan semua isi panduan ini dalam satu malam—akhirnya Anda tidak akan melakukan apa pun. Lakukan tiga langkah terpenting hari ini:

1. Periksa rahasia Anda. Buka .gitignore, pastikan .env tercantum, lalu periksa bahwa tidak ada kunci di repositori publik. Jika ada yang bocor, cabut dan terbitkan ulang.
2. Tanyakan tentang RLS. Beri tahu agen: “tampilkan tabel yang RLS-nya dinonaktifkan”—lalu aktifkan RLS di setiap tabel yang menyimpan data orang.
3. Siapkan pencadangan yang sering. Agar jika terjadi masalah, Anda kehilangan hitungan menit, bukan hari.

Kemudian ikuti daftar periksa di atas seiring berkembangnya proyek dan mulai menangani uang serta data orang lain.

Satu hal terakhir. Keamanan vibe coding adalah tanggung jawab pemiliknya. Anda tidak perlu menjadi pakar keamanan. AI membangun produk Anda dalam satu malam—bagus, tetapi Anda tetap bertanggung jawab atas produk tersebut. Tingkat dasar dalam panduan ini menunjukkan seperti apa tanggung jawab itu dalam praktik.

Aturan keamanan harus menjadi bagian dari metodologi ini agar AI membangun produk dengan benar sejak awal.

Untuk melanjutkan pekerjaan dengan model, kunjungi Ailoot.