Build It vs Break It: Kenapa Vibe Coder Sering Bikin Aplikasi yang Mudah Dibobol

06-04-2026

Ada sebuah pola yang sudah sering terjadi belakangan ini. Seorang developer/vibe coder membangun sebuah aplikasi dalam waktu singkat, men-deploy-nya ke publik, mendapat traction di media sosial, lalu beberapa waktu kemudian ada yang reply dengan database-nya bocor.

Bukan karena developer-nya bodoh. Bukan karena teknologi yang dipakai buruk. Tapi karena ada satu hal yang sering terlewat ketika kita terlalu fokus pada kecepatan: keamanan.

Di artikel ini kita akan membahas mindset Build It vs Break It. Why matter?, di mana para vibe coder kurang teliti terhadap keamanan dan hanya fokus dihasil produknya saja, lalu bagaimana cara berpikir yang lebih aman tanpa harus mengorbankan kecepatan development? di sini saya mencoba membahas secara singkat.

Dua Pola Pikir yang Saling Bertabrakan

Dalam dunia software development, ada dua ekstrem yang sering bertemu:

Yang pertama adalah mentalitas “yang penting jalan dulu”. Fokusnya adalah kecepatan: fitur selesai, demo sukses, deploy done. Ini bukan hal yang salah, terutama ketika sedang di fase awal validasi ide atau MVP. Masalahnya muncul ketika mentalitas ini terbawa terus ke production bahkan setelah aplikasi sudah dipakai orang banyak dan tidak banyak dari level manajerial sering nge-push developer sehingga mereka lebih senang menggunakan cara ini.

Yang kedua adalah mentalitas “harus sempurna dulu”. Developer tipe ini butuh waktu lama karena mereka terlalu detail di setiap sudut kode. Ini juga punya masalah sendiri - product tidak pernah selesai, kalah cepat dengan kompetitor.

Tapi di dimensi lain yang sering luput dari keduanya adalah apakah aplikasi ini aman?

Bukan “sudah ada login page belum?”, tapi aman dalam arti yang sesungguhnya. Aman dari manipulasi input. Aman dari akses tidak sah. Aman dari kebocoran data yang tidak disengaja, pada intinya semua orang ingin aplikasinya aman, namun pada saat proses development sering ketinggalan bahkan banyak ditinggalkan karena dianggap membuat lama proses development.

Apa Itu Build It vs Break It?

Konsepnya sederhana. Kamu membangun sesuatu, lalu kamu melakukan analisa atau secara langsung untuk mencoba menghancurkannya sendiri sebelum orang lain yang melakukannya.

Build It adalah proses pengembangan dalam Software Development Lifecycle (SDLC), di mana sistem dirancang, diimplementasikan dan diintegrasikan berdasarkan kebutuhan fungsional, mencakup perancangan fitur, penulisan kode, hingga deployment agar aplikasi dapat digunakan sesuai dengan tujuan bisnis.

Break It adalah proses berpikir seperti seorang attacker merepresentasikan praktik threat modeling dalam Secure Software Development Lifecycle (Secure SDLC), dimana sistem dianalisis dari perspektif attacker untuk mengidentifikasi potensi misuse, attack surface, kelemahan validasi input, serta celah pada mekanisme authentication dan authorization.

Ini bukan soal menjadi paranoid. Ini soal memiliki kesadaran bahwa setiap sistem yang kamu buat akan dihadapkan pada pengguna yang sebagian dari mereka akan mencoba hal-hal yang tidak kamu bayangkan sebelumnya.

Jika kamu yang membangunnya, idealnya kamu juga yang pertama kali menemukannya celahnya - bukan orang lain.

Fenomena Vibe Coding dan Masalah di Baliknya

Istilah “vibe coding” mulai populer untuk menggambarkan gaya development yang sangat mengandalkan AI tools seperti Cursor, Copilot, Claude atau ChatGPT untuk menulis hampir semua kode. Developer tinggal mendeskripsikan apa yang diinginkan, AI yang nulis dan hasilnya di-paste begitu saja.

Ini bukan sesuatu yang buruk secara fundamental. AI tools memang bisa mempercepat development secara signifikan. Masalahnya bukan di tools-nya, masalahnya ada di cara developer menggunakannya tanpa memahami apa yang dihasilkan.

Ketika kamu meng-generate kode tanpa memahami alurnya, kamu tidak akan tahu:

Apakah kode itu melakukan validasi input dengan benar
Apakah ada asumsi yang salah tentang siapa yang bisa akses endpoint tertentu
Apakah ada data sensitif yang ikut ter-expose dalam response API
Apakah library yang dipakai punya known vulnerability

Hasilnya adalah aplikasi yang secara visual terlihat profesional, demo-nya mulus, tapi di baliknya penuh dengan celah yang tidak pernah disadari oleh pembuatnya sendiri :)

Dari Viral ke Kebobolan: Pola yang Berulang

Jika pembaca sering browsing di X (Twitter), pasti pernah lihat pola ini:

Seseorang post “I built this app in 2 hours using AI”, dapat ribuan likes dan retweet. Orang-orang mulai mencobanya. Traffic naik drastis. Lalu tidak lama kemudian, ada yang menemukan celah. Database di-dump. Tidak lama kemudian aplikasinya dimatikan.

Ini bukan kejadian satu atau dua kali, sudah terjadi berulang kali dan frekuensinya makin tinggi seiring semakin populernya vibe coding.

Kenapa bisa terjadi? Biasanya kombinasi dari beberapa hal:

Pertama, aplikasi di-deploy langsung ke publik tanpa melalui security review apapun. Tidak ada yang duduk dan bertanya “bagaimana kalau ada yang coba inject SQL di sini?”
Kedua, endpoint yang harusnya protected tidak dilindungi dengan benar. Mungkin ada pengecekan login di frontend, tapi tidak ada pengecekan di sisi server.
Ketiga, API keys atau credentials terkadang ikut ter-push ke repository publik karena developer tidak memahami cara pengelolaan secrets yang benar.
Keempat, tidak ada rate limiting, sehingga siapa pun bisa melakukan ribuan request per menit untuk brute force atau scraping data.
Kelima, masih banyak lagi.

Prinsipnya sederhana: begitu kamu expose sesuatu ke internet, dalam hitungan menit sudah ada bot yang menscan dan mencoba berbagai attack vector. Bukan asumsi, ini fakta. Kalau kamu punya VPS public, coba cek log percobaan login ssh.

Tujuh Masalah Umum yang Sering Ditemukan

Security by Accident

Banyak aplikasi yang “belum pernah kena serangan” bukan karena aman, tapi karena belum ketahuan atau belum ada yang nyerang. Ini beda jauh dengan “secure by design”.

Security by accident artinya kamu beruntung dan keberuntungan bukan sebuah strategi yang bisa diandalkan, terutama ketika aplikasi kamu sudah punya pengguna dan data production.

Over-Reliance on Framework Defaults

Framework modern seperti Laravel, Django, Rails, atau Next.js memang menyediakan banyak fitur keamanan bawaan. Tapi ini sering disalahartikan sebagai “framework udah handle semua, aku tinggal pakai”.

Kenyataannya, framework hanya membantumu menghindari kesalahan umum tapi tidak bisa menggantikan pemahaman kamu tentang apa yang sedang terjadi. Ketika kamu tidak paham cara kerja session management, token validation, atau CSRF protection, kamu bisa dengan mudah misconfigure sesuatu yang harusnya aman menjadi vulnerable.

Semua kembali ke “Man behind the gun”-nya, karena dengan menggunakan framework, bisa saja kita sebagai developer tidak mengikuti aturan dari Framework itu sendiri.

Copy-Paste Driven Development

Stack Overflow, forum Reddit dan AI tools adalah sumber yang sangat berguna. Tapi ada perbedaan antara memahami kode yang kamu ambil dan sekadar menyalinnya.

Kode dari internet, termasuk yang dihasilkan AI sering ditulis untuk konteks yang berbeda. Contoh yang ditulis untuk mendemonstrasikan suatu konsep biasanya tidak include security considerations. Kalau kamu paste-nya langsung tanpa modifikasi dan tanpa pemahaman, kamu bisa memasukkan vulnerability yang tidak kamu sadari.

Tidak Ada Threat Modeling

Threat modeling adalah proses sederhana di mana kamu duduk dan bertanya: siapa yang mungkin menyerang sistem ini, apa yang mereka inginkan, dari mana mereka bisa masuk dan apakah setiap fitur aplikasimu sudah menyiapkannya atau tidak?

Jarang ada developer, apalagi vibe coder yang melakukan ini. Padahal ini bukan proses yang harus formal atau butuh tool khusus. Cukup dengan pertanyaan-pertanyaan dasar seperti: apakah ada data di sini yang berharga untuk dicuri? Siapa yang seharusnya tidak bisa akses fitur ini? Apa yang terjadi kalau seseorang mengirimkan input yang tidak terduga?

Tanpa threat model, kamu membangun sistem dengan blind spot yang besar.

Insecure by Design

API yang buruk adalah salah satu sumber vulnerability terbesar di aplikasi modern. Beberapa pola umum yang sering ditemukan:

Endpoint yang mengembalikan lebih banyak data dari yang diperlukan - misalnya, /api/user/123 mengembalikan seluruh object user termasuk password hash dan data internal yang harusnya tidak pernah keluar ke client.

ID yang bisa ditebak. Kalau kamu bisa akses /api/order/1001, coba /api/order/1000 - apakah order orang lain ikut kebuka? Ini yang disebut IDOR (Insecure Direct Object Reference) dan merupakan salah satu vulnerability paling umum di OWASP Top 10.

Tidak ada authorization check yang proper. Mungkin ada autentikasi (membuktikan siapa kamu), tapi tidak ada otorisasi (membuktikan kamu boleh akses resource ini).

Debug Mode di Production

Ini kesalahan yang lebih sering terjadi dari yang dibayangkan. Developer lupa mematikan debug mode ketika deploy ke production dan hasilnya adalah stack trace yang sangat detail muncul setiap kali ada error.

Buat attacker, ini seperti peta. Dengan stack trace attacker bisa memetakan nama file, struktur direktori, library yang dipakai beserta versinya dan kadang potongan kode yang sedang dieksekusi. Semua ini bisa digunakan untuk menyusun serangan yang lebih terarah.

“Works on My Machine” Mentality

Testing di local development environment saja tidak cukup. Environment production punya karakteristik yang berbeda, konfigurasi yang berbeda, variabel yang berbeda dan yang paling penting pengguna yang tidak terduga.

Tanpa proper testing terutama tanpa security testing, kamu tidak punya gambaran yang akurat tentang kondisi aplikasi kamu di production env.

Cara Berpikir Break It: Pertanyaan yang Harus Selalu Ditanya

Setiap kali kamu selesai membangun sebuah fitur, biasakan tanya ke diri sendiri hal-hal berikut:

Apa yang terjadi kalau input di field ini diisi dengan karakter aneh, script HTML, atau SQL query? Apakah aplikasi kamu menanganinya dengan benar atau crash?
Apakah endpoint ini bisa diakses oleh user yang tidak login? Kalau tidak bisa, apakah pengecekan dilakukan di server atau cuma di frontend?
Kalau saya punya akun user biasa, apakah saya bisa akses data atau fungsi yang harusnya cuma untuk admin?
Apakah response API saya memberikan informasi lebih dari yang dibutuhkan?
Kalau seseorang mengirim ribuan request ke endpoint ini dalam satu menit, apa yang terjadi?
Pertanyaan-pertanyaan ini tidak butuh keahlian khusus untuk ditanya. Butuhnya adalah kebiasaan dan disiplin.
Dan lain lain

Fundamental yang Sering Diabaikan

Validasi Input

Setiap data yang datang dari user harus dianggap tidak aman sampai terbukti sebaliknya. Ini prinsip paling dasar dalam web security.

Contoh yang rentan:

// INSECURE SQL QUERY
const query = "SELECT * FROM users WHERE username = '" + req.body.username + "'"

Kalau ada yang memasukkan ' OR '1'='1 sebagai username, query di atas bisa mengembalikan semua user di database. Ini SQL Injection 101, salah satu vulnerability tertua di dunia web namun masih eksis sampai sekarang.

Gunakan parameterized query atau prepared statement:

// Secure SQL Query
const query = "SELECT * FROM users WHERE username = ?"
db.execute(query, [req.body.username])

Selain SQL Injection, validasi input juga penting untuk mencegah XSS (Cross-Site Scripting), ketika attacker bisa inject script HTML ke dalam halaman yang dibuka user lain.

Autentikasi dan Otorisasi

Autentikasi adalah memastikan kamu tahu siapa yang sedang mengakses sistem. Otorisasi adalah memastikan mereka hanya bisa akses apa yang mereka diizinkan.

Keduanya harus dilakukan di sisi server, bukan hanya di sisi client. Menyembunyikan tombol di frontend bukan otorisasi, it’s just a view dan siapa pun bisa memanipulasi request langsung tanpa melalui UI alias banyak jalan menuju roma.

Password dan Credential

Password tidak boleh disimpan dalam bentuk plaintext dan tidak cukup hanya di-hash dengan MD5 atau SHA1. Gunakan algoritma yang dirancang khusus untuk hashing password seperti bcrypt atau Argon2, yang memiliki sistem hash yang kuat.

Jangan pernah hardcode API key, database credentials, atau secret apapun langsung di dalam kode. Gunakan environment variables dan pastikan file .env tidak pernah masuk ke repository apalagi bisa diakses dari public.

Rate Limiting

Tanpa rate limiting, endpoint apapun di aplikasimu bisa diserang dengan ribuan request dalam waktu singkat. Login endpoint bisa di-brute force. API endpoint bisa di-scrape habis-habisan. Bahkan endpoint yang “tidak penting” bisa digunakan untuk distributed denial of service.

Implementasi rate limiting tidak harus kompleks - sebagian besar framework dan platform sudah menyediakan solusi yang mudah dipakai.

Common Vulnerability - CSRF

Cross-Site Request Forgery adalah serangan di mana attacker membuat korban secara tidak sadar mengirimkan request ke aplikasi kamu dengan menggunakan session korban yang sedang aktif. Tanpa CSRF protection, attacker bisa membuat form di website mereka sendiri yang, ketika diklik oleh korban, akan mengirim request ke aplikasi kamu atas nama korban.

Menyatukan Build dan Break dalam Workflow

Mindset ini bukan tentang memperlambat development. Ini tentang memastikan apa yang kamu build tidak harus di-rebuild dari nol setelah terjadi insiden.

Beberapa hal praktis yang bisa langsung diterapkan:

Sebelum deploy, luangkan 15-30 menit untuk mencoba “menyerang” fitur yang baru kamu buat. Coba edge case yang aneh. Coba akses endpoint langsung tanpa melalui UI.
Gunakan tool seperti OWASP ZAP atau Burp Suite (community edition-nya gratis) untuk basic security scanning. Kamu tidak harus jadi expert untuk menjalankannya.
Set up logging yang proper. Kamu tidak bisa defend apa yang tidak kamu monitor. Ketahui kapan ada unusual activity di aplikasi kamu.
Ikuti vulnerability disclosure dari framework dan library yang kamu pakai. Kalau ada security update, jangan tunda-tunda untuk update.

Tentang Trade-off antara Kecepatan dan Keamanan

Ada anggapan bahwa keamanan adalah penghalang kecepatan. Ini tidak sepenuhnya salah memang ada memang trade-off di sini. Tapi trade-off itu sering dilebih-lebihkan.

Security best practices seperti parameterized query, validasi input dan proper authentication tidak membutuhkan waktu extra yang signifikan kalau sudah menjadi kebiasaan. Yang butuh waktu banyak adalah memperbaiki kerusakan setelah terjadi insiden, investigasi, komunikasi ke pengguna, perbaikan sistem dan membangun kembali kepercayaan.

Kecepatan yang mengorbankan keamanan adalah hutang teknis dan hutang ini bunganya bisa sangat mahal.

Penutup

Banyak aplikasi tidak gagal karena alasan teknis yang kompleks. Mereka gagal karena mindset yang salah sejak awal.

Vibe coding bukan masalah. Menggunakan AI untuk mempercepat development bukan masalah. Masalahnya adalah ketika kecepatan menjadi satu-satunya ukuran keberhasilan dan keamanan dianggap sebagai concern yang bisa ditunda.

Di internet, tidak ada “nanti diperbaiki setelah ada masalah” karena ketika masalah itu datang, sering sudah terlambat. Data sudah bocor, kepercayaan pengguna sudah hilang.

Jadikan “bagaimana seseorang bisa menyalahgunakan ini?” sebagai pertanyaan rutin, bukan afterthought. Bangun cepat tapi bangun dengan sadar dan mata terbuka.

Karena begitu aplikasi kamu online, seseorang sudah mulai mencoba membobolnya dan lebih baiknya kamu yang menemukan celahnya lebih dulu.