# Keselamatan Vibe Coding: Cara Melindungi Aplikasi Binaan AI
> Cara mengelakkan aplikasi yang dibina dengan AI daripada digodam: kebocoran Lovable dan Tea, melindungi rahsia dan kunci, RLS, kebenaran ejen serta senarai semak keselamatan sebelum penerbitan.
Source: https://ailoot.ai/blog/ms/vibe-coding-security/
Canonical: https://ailoot.ai/blog/ms/vibe-coding-security/
Language: ms
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-014
Revision: sha256-bb37109e448af6ce78c4f974d148222a609fc062ae886e86d457572b8a47555c
Inti utama
Aplikasi yang dibina dengan AI digodam bukan kerana AI itu bodoh, tetapi kerana secara lalai ia meninggalkan kelemahan yang boleh dijangka: pangkalan data terbuka tanpa RLS, kunci terus dalam kod dan pemeriksaan kebenaran hanya pada antara muka. Pada Mei 2026, imbasan terhadap 380,000 aplikasi binaan vibe coding menemui kira-kira 5,000 aplikasi yang membocorkan data orang lain. Saya akan terangkan kelemahan yang ada dan memberikan senarai semak perkara yang perlu diperiksa sendiri, walaupun anda bukan pengatur cara.
Lebih banyak arahan untuk menggunakan Ailoot terdapat dalam [dokumentasi](https://ailoot.ai/docs/).
## Mengapa aplikasi binaan AI lebih kerap digodam?
Inti utama
Kerana AI mengoptimumkan kod supaya “berfungsi” dan tidak memikirkan sama ada ia “selamat”. AI membiarkan pangkalan data terbuka kepada umum secara senyap, meletakkan kunci dalam kod dan memeriksa kebenaran hanya pada skrin. Menurut pelbagai kajian, 40 hingga 62 peratus kod yang dijana AI mengandungi kerentanan. Sebagai pemilik, anda tidak akan mengetahuinya sehingga bil tiba atau data bocor.
Saya sendiri membina produk dengan AI, dan saya tidak paranoid tentang keselamatan sehingga mahu “mengunci semuanya semaksimum mungkin”. Namun, ada tahap asas yang tidak boleh anda abaikan, jika tidak suatu hari nanti anda akan terjaga dengan pangkalan data kosong dan pelombong milik orang lain pada pelayan anda. Panduan ini tentang tahap asas itu. Bukan “jadilah pakar keselamatan”, tetapi “jangan sengaja memudaratkan diri sendiri”.
Punca masalah ini mudah. Apabila anda berkata kepada ejen AI, “bina aplikasi untuk membuat janji temu pelanggan”, ejen itu akan memastikan aplikasi berfungsi secepat mungkin. Keselamatan ialah kerja tambahan yang tidak kelihatan dalam demo. Jadi pangkalan data ditetapkan supaya terbuka, kunci pembayaran dimasukkan terus ke dalam kod, dan semakan “adakah pengguna ini mempunyai akses?” hanya wujud dalam pelayar, tempat ia boleh dipintas dalam sekelip mata.
Sebab kedua ialah platform itu sendiri. Punca strukturnya mudah: banyak platform menjadikan projek baharu boleh diakses umum secara lalai, dan pembina yang bukan pengatur cara tidak selalu tahu bahawa tetapan ini perlu diubah.
Dengan kata lain, kelemahan itu muncul sendiri sebagai tetapan lalai. Anda tidak melakukan kesalahan. Anda cuma tidak melakukan apa-apa — dan dalam keselamatan, tidak bertindak bermaksud tepat-tepat “terbuka kepada semua orang”.
Logiknya jelas: ejen menjalankan `git add .` dan `git push` tanpa melihat kandungannya, lalu fail `.env` anda yang mengandungi kunci turut menjadi umum bersama semua yang lain.
## Apakah yang telah dipelajari oleh pembina vibe coding melalui pengalaman pahit?
Inti utama
Mereka terkena tiga masalah yang sama: RLS dimatikan, storan terbuka tanpa pemeriksaan kebenaran dan kunci dalam kod. Lovable mendedahkan data daripada 170 aplikasi; aplikasi Tea membocorkan kira-kira 72,000 foto dan lebih sejuta mesej peribadi. Setiap kes mempunyai laporan awam dengan nombor kerentanan yang diberikan.
Cara terbaik mengelakkan kecuaian ialah belajar daripada kesilapan orang lain. Berikut empat laporan yang wajar anda baca sebelum menerbitkan projek.
**Lovable dan RLS yang dimatikan.** Platform Lovable membina aplikasi daripada penerangan teks. Pada 2025, satu kelemahan sistemik ditemui dalam aplikasinya dan diberikan pengenal pasti CVE-2025-48757. Puncanya: aplikasi yang dijana tidak mempunyai peraturan akses pangkalan data pada peringkat baris (RLS, diterangkan di bawah). Seorang penyelidik memeriksa sampel dan menemui 303 titik akses terdedah merentas 170 aplikasi. Nama, nombor telefon, status pembayaran, kunci API orang lain malah alamat rumah turut terdedah. Dalam kira-kira 70 peratus aplikasi yang diperiksa, perlindungan pada peringkat baris dimatikan sepenuhnya.
**Tea dan data sensitif.** Aplikasi Tea (ulasan tanpa nama tentang orang) kehilangan kira-kira 72,000 imej pada Julai 2025, termasuk 13,000 swafoto dan foto dokumen, kemudian lebih sejuta mesej peribadi. Punca teknikalnya ialah storan terbuka dan pemeriksaan akses yang lemah. Komuniti keselamatan menjadikan Tea contoh yang jelas: apabila pelancaran pantas lebih penting daripada pemeriksaan kebenaran, data sensitif ialah perkara pertama yang bocor.
**Satu lagi contoh praktikal.** Dalam kes yang dihuraikan oleh penulis asal, aplikasi seorang pembina vibe coding digodam kerana AI menetapkan kata laluan lalai ketika mencipta pangkalan data — kata laluan yang boleh diteka secara automatik. Kemudian berlaku urutan biasa: penceroboh masuk, memasang pelombong dan menulis semula projek. Pelayan itu terpaksa dipadam sepenuhnya. Kata laluan lalai ibarat pintu tidak berkunci dengan papan tanda “silakan masuk”.
Perhatian
Perhatikan persamaan dalam keempat-empat cerita ini: tiada satu pun melibatkan “penggodam yang bijak”. Dalam setiap kes, kelemahan itu terbuka secara lalai, dan pemiliknya tidak tahu bahawa ia perlu ditutup. Semua perkara di bawah menerangkan cara menutup pintu ini lebih awal.
## Dua medan keselamatan: di manakah sebenarnya kelemahan anda?
Inti utama
Ada dua ancaman yang berbeza. Pertama ialah ejen AI itu sendiri: anda memberinya akses kepada komputer, kunci dan pangkalan data, dan ia boleh merosakkan atau mengambil sesuatu walaupun tanpa niat jahat. Kedua ialah aplikasi yang telah siap: perkara yang anda letakkan di Internet dan diserang orang lain. Kedua-duanya memerlukan perlindungan berbeza, jadi saya akan membincangkannya satu demi satu di bawah.
Apabila orang bercakap tentang “keselamatan vibe coding”, mereka biasanya mencampuradukkan dua kebimbangan yang sama sekali berbeza. Mari kita pisahkan, kerana perlindungannya berlainan.
**Medan pertama — ejen itu sendiri.** Anda menjalankan ejen AI pada komputer dan memberinya akses kepada fail, terminal, kunci dan pangkalan data. Risikonya ialah ejen bukan manusia: ia mengikut arahan secara literal dan mencari jalan paling singkat, walaupun jalan itu berbahaya. Ini juga merangkumi risiko arahan orang lain “disuntik” ke dalam ejen melalui teks yang dibacanya (ini dipanggil prompt injection).
**Medan kedua — aplikasi yang telah siap.** Inilah perkara yang anda terbitkan dan digunakan orang ramai. Sasaran ialah laman atau perkhidmatan anda yang diterbitkan: penyerang menceroboh pangkalan data terbuka, menghantar permintaan palsu atau meneka akaun orang lain. Ejen tidak terlibat — kelemahan itu telah ditinggalkan lebih awal, lalu dieksploitasi orang lain.
Anthropic, syarikat di sebalik Claude, menyatakan prinsip perlindungan utama begini — dan ia terpakai pada kedua-dua medan:
Reka bentuk perlindungan pada peringkat persekitaran terlebih dahulu, kemudian barulah urus tingkah laku model.
— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude
Dalam praktiknya, maksudnya ialah jangan bergantung pada AI untuk “mengelakkan perkara buruk dengan sendirinya”. Hadkan dahulu perkara yang boleh dilakukannya secara fizikal, kemudian barulah minta ia berkelakuan baik. Apabila tingkah lakunya gagal — dan ia akan gagal — hanya sempadan kukuh yang anda tetapkan lebih awal akan melindungi anda.
Mahukan AI bekerja dengan boleh dijangka dan berhenti memudaratkan anda dalam setiap projek baharu? Peraturan keselamatan ialah sebahagian daripada Second Brain anda: tuliskannya sekali dalam `CLAUDE.md`, dan ejen akan mengikutinya pada setiap permintaan.
## Apakah yang boleh dilakukan oleh ejen AI dengan akses kepada komputer anda?
Inti utama
Ejen mengikut arahan secara literal dan akan mencari jalan penyelesaian yang tidak anda jangkakan. Pada Mei 2026, ejen Codex tanpa kebenaran pentadbir menyedari pengguna mempunyai akses kepada Docker lalu menggunakannya untuk mendapatkan akses root penuh. Pengajarannya: jangan berikan ejen lebih banyak kebenaran daripada yang diperlukan untuk tugas itu, dan jangan jalankannya pada mesin produksi dalam mod “benarkan semua”.
Risiko yang paling dipandang ringan ialah ejen anda sendiri dengan kebenaran yang terlalu luas. Anda tidak memerlukan penggodam dari luar pun. Ejen Codex memerlukan kebenaran pentadbir yang tidak dimiliki pengguna. Ejen itu tidak mengalah — ia melihat sekeliling, mendapati pengguna tergolong dalam kumpulan `docker`, yang pada hakikatnya setara dengan root, lalu menggunakan akses itu.
Tiada niat jahat di sini. Ejen yang diberitahu “selesaikan tugas ini” hanya menemui kelemahan struktur dengan lebih pantas daripada manusia. Jika kelemahan itu memberinya akses kepada kunci atau produksi anda, ia akan menggunakannya. Jadi peraturan nombor satu ialah **keistimewaan minimum**. Berikan ejen akses yang tepat setakat yang diperlukan untuk tugas tertentu, tidak lebih.
Apakah yang boleh anda lakukan secara praktikal, walaupun anda bukan pengatur cara?
1. ### Jangan jalankan ejen dalam mod “benarkan semua” pada mesin produksi
Mod yang tidak meminta pengesahan daripada ejen (sering dipanggil bypass atau yolo) hanya sesuai untuk sandbox atau projek ujian, bukan mesin yang menyimpan kunci aktif dan akses produksi.
2. ### Larang ejen membaca rahsia
Dalam Claude Code, anda boleh menetapkan peraturan yang menafikan akses kepada fail yang mengandungi kunci. Jadi, walaupun ejen mahu membuka `.env`, alat itu tidak akan membenarkannya.
3. ### Asingkan kunci produksi
Kunci untuk pangkalan data produksi dan perkhidmatan pembayaran tidak sepatutnya berada dalam folder yang sama tempat ejen menulis kod. Asingkan persekitaran: gunakan kunci ujian semasa membuat eksperimen.
4. ### Gunakan sandbox alat tersebut
Alat AI moden boleh menjalankan arahan secara terasing (dalam sandbox), tanpa akses kepada bahagian lain sistem. Dalam Claude Code, ini mengurangkan permintaan kebenaran kira-kira 84 peratus — jadi ia juga lebih mudah digunakan.
Peraturan yang melarang pembacaan rahsia dalam Claude Code boleh kelihatan lebih kurang begini — letakkannya dalam tetapan kebenaran:
```json
{
"permissions": {
"deny": [
"Read(.env)",
"Read(**/.env)",
"Bash(git push *)"
]
}
}
```
Nota
Peringatan penting: peraturan yang menafikan pembacaan meliputi alat terbina dalam ejen dan arahan fail yang mudah. Tetapi jika ejen menjalankan skripnya sendiri untuk membuka fail, peraturan itu tidak akan menghalangnya. Oleh itu, sempadan kukuh ialah sandbox peringkat sistem, bukan sekadar senarai larangan. Persekitaran dahulu, tingkah laku kemudian.
## Di manakah anda tidak patut meletakkan kunci API dan kata laluan?
Inti utama
Hanya dalam fail `.env` yang disenaraikan dalam `.gitignore`, dan jangan sekali-kali dalam kod atau repositori awam. Bot akan menemui kunci yang terlepas ke repositori awam dalam masa kurang seminit dan mula membelanjakan wang anda. Pada 2025, 28.65 juta rahsia bocor ke repositori awam GitHub. Jika kunci sudah bocor, memadamkannya sahaja tidak mencukupi — anda perlu membatalkannya dan mengeluarkan kunci baharu.
Kesilapan yang paling murah dan paling lazim ialah meletakkan kunci dalam kod. Kunci API untuk perkhidmatan pembayaran, kata laluan pangkalan data, token bot — semuanya rahsia. Semuanya perlu disimpan dalam fail `.env` yang berasingan, dan fail itu mesti disenaraikan dalam `.gitignore` supaya tidak dimasukkan ke git bersama kod.
Urutan yang biasa berlaku: bot mengesan kunci awan, melancarkan pelayan perlombongan mata wang kripto dengan wang anda, dan menjelang pagi anda menerima bil berjumlah puluhan ribu. Pembangun kerap berkongsi kisah seperti ini, dan bilnya mencecah lima angka dalam dolar.
Skala masalah pada 2025: 28.65 juta rahsia baharu yang dikodkan terus ke dalam repositori awam, meningkat 34 peratus berbanding tahun sebelumnya. Kebocoran kunci khusus untuk perkhidmatan AI meningkat 81 peratus. Vibe coding menambahkan masalah kerana ejen membuat commit tanpa memeriksa kandungannya.
Perkara yang boleh anda periksa sendiri sekarang:
1. ### Buka fail .gitignore projek
Pastikan fail itu mempunyai baris `.env`. Jika tiada, tambahkannya sebelum commit pertama.
2. ### Pergi ke repositori GitHub anda
Pastikan fail `.env` tiada di situ. Mencari `.env` atau sebahagian daripada kunci anda dalam repositori ialah cara pantas untuk memeriksanya.
3. ### Jika kunci bocor, batalkan dan keluarkan kunci baharu
Memadam commit sahaja tidak mencukupi: kunci itu mungkin sudah diambil. Pergi ke perkhidmatan tersebut (penyedia pembayaran, perkhidmatan awan, penyedia AI), batalkan kunci lama dan keluarkan kunci baharu. Proses ini dipanggil penggiliran kunci.
4. ### Berikan kebenaran minimum kepada kunci
Jika kunci hanya diperlukan untuk membaca, jadikannya baca sahaja. Jadi, walaupun ia bocor, kuranglah perkara yang boleh dicuri.
## Mengapa semua orang boleh melihat pangkalan data anda tanpa RLS?
Inti utama
RLS (Row Level Security) ialah penapis automatik yang ditambahkan oleh pangkalan data pada setiap permintaan supaya pengguna hanya melihat baris milik mereka sendiri. Tanpanya, sesiapa sahaja yang mempunyai kunci awam aplikasi boleh membaca dan mengubah semua data. Perangkap utama: apabila AI mencipta jadual melalui SQL, RLS dimatikan secara lalai. Itulah yang menyebabkan data daripada 170 aplikasi Lovable bocor.
Jika anda membina aplikasi pada Supabase atau pangkalan data yang serupa, inilah bahagian paling penting. RLS bermaksud Row Level Security. Secara mudahnya, ia ialah peraturan yang menentukan baris dalam jadual yang ditunjukkan kepada pengguna tertentu. Tanpanya, jadual “orders” akan memaparkan pesanan semua pelanggan kepada semua orang.
Dokumentasi Supabase sendiri menyatakannya dengan jelas:
Mana-mana jadual tanpa RLS boleh diakses secara umum melalui API.
— Dokumentasi Supabase, https://supabase.com/docs/guides/database/postgres/row-level-security
Inilah perangkap utama bagi pembina vibe coding. Apabila anda mencipta jadual melalui papan pemuka Supabase, perlindungan diaktifkan secara automatik. Tetapi apabila AI mencipta jadual — dan hampir selalu ia menulis arahan SQL secara langsung — RLS kekal dimatikan secara lalai. Ini bermakna jadual yang dijana ejen hampir pasti terbuka kepada seluruh Internet. Itulah yang menyebabkan kebocoran pada 170 aplikasi Lovable tersebut.
Perkara yang perlu dilakukan:
1. ### Tanya ejen secara langsung
Tulis: “tunjukkan semua jadual yang RLS-nya dimatikan”. AI akan menghasilkan senarai — itulah senarai kerja anda.
2. ### Aktifkan RLS pada setiap jadual yang mempunyai data pengguna
Tambahkan sekurang-kurangnya satu dasar akses — contohnya, “pengguna hanya boleh melihat baris miliknya sendiri”.
3. ### Periksa papan pemuka
Dalam papan pemuka Supabase, setiap jadual sepatutnya menunjukkan “RLS enabled”. Jika statusnya kelabu atau merah, jadual itu terbuka.
4. ### Uji dengan betul
Log masuk sebagai pengguna biasa dan cuba meminta data orang lain. Jika akses ditolak, dasar itu berfungsi.
## Mengapa pemeriksaan kebenaran pada antara muka tidak melindungi anda?
Inti utama
Kerana penyerang tidak mengklik butang pada antara muka anda — mereka menghantar permintaan terus kepada pelayan. Jika anda menyembunyikan butang “padam” atau hanya memaparkan data orang lain kepada pengguna “yang dibenarkan” pada peringkat skrin, perkara itu boleh dipintas dalam sekelip mata. Periksa sama ada pengguna dibenarkan melakukan tindakan pada pelayan (backend), bukan sekadar dalam pelayar.
Ilusi yang biasa berlaku ialah: “Saya sudah memastikan pengguna biasa tidak dapat melihat butang pentadbir.” Masalahnya, butang hanyalah gambar dalam pelayar. Permintaan boleh dihantar terus kepada pelayan tanpa menggunakan butang itu. Jika pelayan tidak memeriksa kebenaran sekali lagi, ia akan melaksanakan arahan orang lain.
Contoh klasik dipanggil IDOR. Bayangkan anda membuka pesanan sendiri pada alamat yang mengandungi `id=123`. Tukar kepada `id=124`, lalu anda boleh melihat pesanan orang lain kerana pelayan tidak memeriksa sama ada pesanan itu benar-benar milik anda. Ini antara kelemahan paling lazim dalam aplikasi binaan vibe coding, dan pemeriksaan kebenaran yang lemah menjadi punca kebocoran Tea.
Peraturannya mudah: **ulangi setiap pemeriksaan “adakah pengguna ini dibenarkan melakukan perkara ini?” pada pelayan**. Antara muka memudahkan penggunaan; perlindungan mesti berada pada backend. Arahan yang boleh terus digunakan untuk ejen: “tambahkan pemeriksaan kebenaran pada bahagian pelayan untuk setiap titik akhir yang membaca atau mengubah data pengguna; jangan bergantung pada elemen yang disembunyikan dalam antara muka.”
## Bagaimanakah anda boleh memeriksa kelemahan dalam kod jika bukan pengatur cara?
Inti utama
Dengan tiga alat yang membaca kod seperti jurutera keselamatan. Yang pertama ialah arahan `/security-review` terus dalam Claude Code. Yang kedua ialah pemalam rasmi panduan keselamatan Anthropic, yang memeriksa kod pada setiap suntingan. Yang ketiga ialah koleksi 754 kemahiran keselamatan sedia guna dari GitHub. Penting: tiada satu pun memberikan jaminan 100 peratus; semuanya lapisan perlindungan, bukan pengganti pertimbangan yang waras.
Berita baiknya: kini anda boleh meminta AI yang sama memeriksa keselamatan — ia agak baik dalam menemui kelemahan lazim. Berikut tiga alat untuk tugas yang berbeza.
| Alat | Fungsinya | Bila hendak dijalankan |
|----|----|----|
| `/security-review` | Pemeriksaan sekali bagi satu cabang dengan satu arahan | Secara manual, sebelum penerbitan |
| Pemalam security-guidance | Memeriksa setiap suntingan, pada akhir setiap giliran dan ketika commit | Secara berterusan di latar belakang |
| Koleksi kemahiran GitHub | 754 pemeriksaan berdasarkan piawaian OWASP, MITRE dan NIST | Apabila anda memerlukan pemeriksaan mendalam |
**1. Arahan `/security-review` dalam Claude Code.** Pemeriksaan sekali terhadap cabang semasa untuk mencari suntikan SQL, XSS, kelemahan kebenaran, kebocoran data dan masalah kebergantungan. Saya menerangkan langkah demi langkah cara ia berfungsi dan cara memasang pemeriksaan automatik bagi setiap perubahan dalam panduan berasingan tentang [semakan keselamatan dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-security-review/). Inti utamanya di sini: inilah barisan pertahanan pertama yang dijalankan dengan satu arahan.
**2. Pemalam rasmi security-guidance.** Pasangkannya daripada pasaran pemalam rasmi dengan `/plugin install security-guidance@claude-plugins-official` (memerlukan Claude Code versi 2.1.144 atau lebih baharu). Ia memeriksa kod pada tiga waktu: setiap kali disunting, pada akhir setiap giliran dan ketika commit. Ia mengesan pintasan kebenaran, IDOR, suntikan dan kriptografi yang lemah. Namun Anthropic berterus terang tentang hadnya:
Anggap pemalam ini sebagai satu lapisan pertahanan mendalam, bukan penyelesaian keselamatan yang lengkap.
— Anthropic, dokumentasi panduan keselamatan, https://code.claude.com/docs/en/security-guidance
```bash
npx skills add /
```
Kemudian beritahu ejen: “periksa projek saya untuk mencari kerentanan”. Namun, ada peringatan penting tentang koleksi ini, sebab itulah saya memberikan bahagian berasingan di bawah.
Untuk konteks: pemain utama juga mula mengambil serius keselamatan kod AI. Sebagai sebahagian daripada Project Glasswing, yang diperluas pada 2 Jun 2026 untuk merangkumi 150 organisasi, rakan kongsi menemui lebih 10,000 kerentanan kritikal dalam masa singkat dengan menggunakan model Anthropic. Taruhannya jelas:
Kami menganggarkan bahawa bagi kebanyakan rakan kongsi, serangan besar boleh menjejaskan lebih 100 juta orang.
— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing
## Bolehkah anda mempercayai kemahiran dan sambungan daripada GitHub?
Inti utama
Tidak, bukan secara lalai — periksa dahulu sebelum memasangnya. Setiap kemahiran, pemalam atau sambungan ialah kod orang lain yang akan dijalankan oleh ejen pada mesin anda dengan kebenaran anda. Koleksi yang mempunyai nama “Anthropic” itu sebenarnya dibuat oleh komuniti dan tiada kaitan dengan Anthropic. Sambungan berniat jahat boleh mencuri kunci anda dalam beberapa minit, dan membuang pakej itu tidak semestinya menghapuskannya sepenuhnya.
Inilah bahagian yang paling rumit kerana bahayanya datang daripada alat yang anda pasang untuk tujuan keselamatan. Apabila anda menjalankan `npx skills add ...` atau memasang sambungan, anda mendapatkan kod orang lain yang kemudiannya dijalankan oleh ejen dengan kebenaran anda. Jika pengarangnya digodam atau pakej itu memang berniat jahat sejak awal, anda menghadapi masalah.
Lihat koleksi kemahiran daripada bahagian sebelumnya. Namanya mengandungi “Anthropic”, yang boleh membuat anda leka. Namun, keterangannya sendiri menyatakan dengan jelas:
Ini ialah projek komuniti bebas. Projek ini tidak berafiliasi dengan Anthropic PBC.
— README repositori mukul975
Dengan kata lain, namanya mengelirukan. Koleksi itu sendiri kini matang dan bersih, tetapi prinsipnya tetap sama: anda memasangnya atas risiko sendiri. Ancaman ini bukan teori semata-mata. Pada Mei 2026, sambungan editor berniat jahat berada di pasaran selama 18 minit sahaja — dan dalam masa itu, ia sempat mencuri kata laluan daripada pengurus kata laluan, token GitHub, akses awan malah konfigurasi Claude Code daripada orang yang memasangnya. Satu lagi perkara buruk: perisian hasad seperti itu sering kekal selepas pakej dibuang seperti biasa dan berjalan semula dalam sesi seterusnya.
Saya mengamalkan satu tabiat mudah dan mengesyorkannya kepada anda: sebelum memasang apa-apa kemahiran dari GitHub, periksa sendiri. Pengarang boleh digodam, akaun boleh dirampas dan perisian hasad boleh dimasukkan ke dalam repositori. Pemeriksaan ialah perlindungan anda.
Langkah minimum yang praktikal sebelum memasang: lihat pengarang dan jumlah bintangnya, baca penerangan kemahiran, jangan memasang alat “kerana disyorkan dalam satu hantaran”, dan cuba dahulu alat yang tidak dikenali dalam persekitaran ujian berasingan, bukan pada mesin yang mempunyai kunci produksi.
## Perkara yang menyelamatkan anda selepas pencerobohan: sandaran dan pemulihan
Inti utama
Sandaran terkini dan git. Pangkalan data perlu disandarkan dengan kerap — sekurang-kurangnya setiap setengah jam; salinan setiap tiga hari bermakna anda kehilangan semua yang terkumpul antara salinan. Git membolehkan anda mengembalikan kod kepada keadaan berfungsi apabila ejen merosakkan sesuatu. Lambat-laun, AI akan memadam sesuatu yang penting — persoalannya cuma sama ada anda mempunyai titik pemulihan.
Keselamatan bukan hanya tentang “menghalang orang luar daripada masuk”, tetapi juga tentang “kembali seperti biasa apabila sesuatu tidak kena”. Kerana sesuatu pasti akan berlaku. Dalam kes praktikal yang dihuraikan, ejen AI memadam pangkalan data langsung dalam projek produksi ketika menjalankan tugas rutin. Sandaran ada, tetapi usianya tiga hari — dan data selama tiga hari hilang begitu sahaja.
Ini membawa kepada dua peraturan.
**Buat sandaran dengan kerap.** Jika aplikasi anda mengandungi data yang anda tidak sanggup kehilangan, salinan setiap tiga hari hanyalah ilusi perlindungan. Tetapkan sandaran automatik sekurang-kurangnya setiap 30 minit. Bagi kebanyakan pangkalan data, termasuk Supabase, anda boleh mengaktifkannya dengan beberapa klik.
**Git ialah insurans terhadap ejen.** Git menyimpan sejarah kod anda: anda boleh memulihkan sebarang keadaan yang berfungsi. Apabila ejen menulis semula sesuatu yang berfungsi, kembalilah kepada versi terakhir yang berfungsi dan bukannya membaikinya sendiri. Jika AI memadam atau merosakkan projek dan anda tidak tahu cara memulihkannya, lihat laporan berasingan: [apa yang perlu dilakukan jika AI memadam pangkalan data](https://ailoot.ai/blog/ms/ai-deleted-database-recovery/). Untuk mengetahui cara melindungi projek daripada kerosakan lebih awal, lihat panduan [cara melindungi Claude Code daripada kerosakan](https://ailoot.ai/blog/ms/claude-code-safe-overnight-setup/).
## Senarai semak keselamatan sebelum penerbitan
Inti utama
Sebelum membuka aplikasi anda kepada umum, semak 10 perkara: rahsia dalam `.env` dan `.gitignore`, RLS diaktifkan, pemeriksaan kebenaran pada pelayan, tandatangan webhook, keistimewaan minimum untuk kunci dan ejen, sandaran terkini, pemeriksaan kod menggunakan alat dan sikap berhati-hati terhadap kemahiran orang lain. Ini senarai semak asas sebelum penerbitan, tanpa peratus liputan diukur atau tempoh siap dijamin. Sahkan senario akses sebenar dalam aplikasi; kotak ditanda sahaja tidak membuktikan perlindungan.
Ikuti senarai ini tepat sebelum penerbitan, mengikut turutan.
1. **Rahsia dalam `.env`, dan `.env` dalam `.gitignore`.** Tiada kunci dalam kod. Tiada fail `.env` dalam repositori awam.
2. **Kunci dengan kebenaran minimum.** Setiap kunci hanya boleh melakukan perkara yang diperlukan. Kunci produksi diasingkan daripada persekitaran ejen.
3. **RLS diaktifkan** pada semua jadual yang mempunyai data pengguna, dan dasar akses telah ditetapkan.
4. **Pemeriksaan kebenaran pada pelayan** untuk setiap operasi data. Menyembunyikan butang dalam antara muka tidak mencukupi. Anda telah menguji sendiri perubahan `id` pada alamat.
5. **Pengesahan tandatangan webhook.** Setiap pengendali pemberitahuan luaran (pembayaran, borang) mengesahkan tandatangannya.
6. **Pengehadan kadar** pada permintaan masuk dan operasi yang mahal, supaya kata laluan tidak boleh diteka melalui serangan brute force dan bil anda tidak melambung.
7. **Ejen tidak berjalan dalam mod “benarkan semua”** pada mesin yang mempunyai kunci produksi. Pembacaan `.env` dilarang.
8. **Sandaran** dibuat dengan kerap dan telah diuji — anda benar-benar pernah mencuba pemulihan, bukan sekadar percaya salinannya “ada di suatu tempat”.
9. **Kod telah diperiksa** dengan `/security-review` atau pemalam security-guidance. Dapatan telah diperbaiki.
10. **Kemahiran dan sambungan orang lain telah diperiksa** sebelum pemasangan. Tiada apa-apa dipasang “secara membuta tuli”.
Petua
Jangan cuba mengunci semuanya serentak seperti kubu — itu boleh melumpuhkan anda. Sesuaikan tahap risiko dengan projek anda: laman ringkas dengan borang dan aplikasi yang mengendalikan pembayaran serta data perubatan memerlukan tahap ketegasan yang berbeza. Namun, lima perkara pertama ialah asas bagi mana-mana projek yang boleh diakses orang lain.
## Di mana hendak bermula hari ini
Inti utama
Mulakan dengan tiga tindakan yang menutup kelemahan paling lazim dan mahal: pastikan `.env` tidak berada dalam repositori awam, tanya ejen jadual mana yang RLS-nya dimatikan dan sediakan sandaran lebih kerap daripada sekali sehari. Pemeriksaan ini titik permulaan berguna, tetapi masa dan liputan bergantung pada aplikasi. Susuli dengan ujian kebenaran serta pemulihan sebenar.
Jangan cuba melaksanakan semua perkara dalam panduan ini dalam satu malam — akhirnya anda tidak akan melakukan apa-apa. Ambil tiga langkah paling penting hari ini:
1. **Periksa rahsia anda.** Buka `.gitignore`, pastikan `.env` disenaraikan dan periksa sama ada terdapat kunci dalam repositori awam. Jika ada yang bocor, batalkan dan keluarkan kunci baharu.
2. **Tanya tentang RLS.** Beritahu ejen: “tunjukkan jadual yang RLS-nya dimatikan” — kemudian aktifkannya di mana-mana tempat data orang disimpan.
3. **Sediakan sandaran yang kerap.** Supaya jika berlaku masalah, anda kehilangan minit dan bukannya hari.
Kemudian, apabila projek berkembang dan mula mengendalikan wang serta data orang lain, ikuti senarai semak di atas.
Satu perkara terakhir. Keselamatan vibe coding ialah tanggungjawab pemilik. Anda tidak perlu menjadi pakar keselamatan. AI membina produk anda dalam satu malam — bagus, tetapi andalah yang bertanggungjawab terhadapnya. Tahap asas dalam panduan ini menunjukkan rupa tanggungjawab itu dalam praktik.
### Sumber
- [Cara Anthropic mengawal Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [Perluasan Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: kebenaran dan peraturan deny (dokumentasi)](https://code.claude.com/docs/en/permissions)
- [Pemalam security-guidance (dokumentasi Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Keselamatan Peringkat Baris (dokumentasi Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 untuk Aplikasi LLM 2025](https://genai.owasp.org/llm-top-10/)
Untuk terus bekerja dengan model, anda boleh pergi ke [Ailoot](https://ailoot.ai/).
## Soalan lazim: Keselamatan Vibe Coding: Cara Melindungi Aplikasi Binaan AI
### Adakah melengkapkan senarai semak membuktikan aplikasi selamat?
Tidak. Ia meliputi pemeriksaan permulaan biasa, tanpa peratus kelemahan dibuang yang dijamin. Uji akses data sebenar sebagai pengguna biasa, semak pengesahan webhook dan sahkan sandaran boleh dipulihkan.
### Mengapakah menyembunyikan butang pentadbir tidak mencukupi?
Penyerang boleh menghantar permintaan asas secara langsung. Pelayan mesti memeriksa identiti serta kebenaran pemanggil bagi setiap operasi, dan data pengguna memerlukan dasar akses pangkalan data yang sesuai.
## Ailoot · Syarikat dan portfolio projeknya
Ailoot berteraskan pengalaman operasi yang mantap, pangkalan pelanggan yang besar, perkhidmatan yang stabil dan pemantauan KPI berterusan.
Syarikat dan portfolio projeknya: jutaan pelanggan; jualan bernilai berbilion setiap bulan.
Ailoot menggunakan pengalaman operasi ini untuk akses API kepada ciri AI dalam produk pelanggan, ejen, aplikasi dan automasi.