Dia Menemukan Pintu Terbuka di Situs Saya Sendiri. Ini Perbaikannya

Arahkan REA ke aplikasimu sendiri sebelum orang lain membongkarnya. Kami mengarahkannya ke situs live kami dari sandbox cloud sekali pakai, memperbaiki apa yang ditemukan, lalu mengirim pull request.

REA adalah skill reverse engineering yang selama ini dipakai banyak video untuk membongkar software milik orang lain. Di situs kami, REA butuh kurang dari tiga belas menit dan tidak satu pun request write untuk membuktikan bahwa situs mana pun bisa mengisi mailing list kami. REA juga menemukan batas harian bot komentar kami tergeletak di dalam JavaScript yang diunduh dari situs kami. Setelah perbaikan, request yang dulu lolos sekarang ditolak.

Hasilnya enam aturan untuk menjalankan audit yang sama pada aplikasimu: sandbox sekali pakai, target yang persis, memilah temuan, config di dalam bundle, rem pada endpoint, dan membuktikan perbaikannya.

REA adalah singkatan dari Reverse Engineer Anything: sekumpulan tool yang membuat Claude Code bisa membongkar aplikasi yang kamu rilis. Reverse engineering berarti mencari tahu cara sesuatu dibuat dari barang jadinya, seperti montir yang membaca mobil tanpa gambar rancangan pabrik.

Alih-alih membaca source code-mu, REA membaca bundle, yaitu JavaScript yang benar-benar dikirim situsmu ke setiap pengunjung. Dari bundle itu REA mendaftar route, endpoint yang dipanggil halamanmu, dan apa pun yang tidak sengaja kamu tinggalkan di sana. REA tidak bisa mengembalikan source-mu, karena yang kamu dapat hanyalah bukti, dan dokumentasinya sendiri menyebut REA bukan sandbox.

Cara menginstalnya:

1. Instal REA dari paket resminya dan kunci versinya, karena REA merilis enam versi dalam satu minggu.
2. Jalankan setup-nya untuk Claude Code.
3. Aktifkan profil compact, karena REA memuat lebih dari seratus tool ke sesimu.
4. Instal hanya dari repo resmi, karena salinan palsu yang berisi malware sudah beredar.

Saat kami menjalankan instalasi di sandbox, agen lebih dulu memeriksa bahwa paketnya menunjuk ke repo resmi sebelum menyentuh apa pun. Setup lalu memasang skill-nya tetapi tidak ada server tool, jadi Claude Code memakai versi command line REA dari tool yang sama. Kalau tool-mu tidak muncul setelah setup, kamu tidak perlu me-restart apa pun: panggil langkah yang sama dari terminal.

Aturan pertama menyangkut tempat menjalankannya. Kamu akan membiarkan agen mengendalikan browser dan menjalankan tool hasil unduhan terhadap aplikasi produksimu. Di laptopmu, agen itu duduk di samping kunci-kuncimu, proyek-proyekmu yang lain, dan setiap akun yang sedang kamu login. Catatan keamanan REA sendiri mengatakannya terang-terangan: ini bukan sandbox.

Sandbox adalah mesin sekali pakai, jadi apa pun yang salah tetap tinggal di dalamnya dan kamu tinggal menghapusnya. Buka sandbox sekali pakai pada repo-mu dan jalankan seluruh audit di sana, jangan pernah di mesinmu sendiri.

Kami memakai Kosuke, yang menjalankan Claude Code dengan langgananmu sendiri di dalam mesin cloud sekali pakai. Kamu memilih repo, memberi tahu agen deploy cara aplikasimu dijalankan, lalu agen memberi preview, yaitu tautan tempat aplikasimu yang sedang berjalan muncul. Setiap chat juga mendapat branch sendiri, artinya salinan kode sendiri, dan berakhir dengan pull request. Saat kami mengimpor situs kami, agen memasang package manager dan browser headless, mengukur memori, dan memilih ukuran mesin sendiri. Beberapa menit kemudian situs asli kami berjalan di samping chat, di branch yang tidak disentuh siapa pun.

Satu jebakan dari tes sebelumnya: aplikasi Next.js baru muncul di preview, tetapi tidak ada yang merespons di halaman. Solusinya satu baris di config Next-mu yang mengizinkan alamat preview, dan halaman langsung hidup.

Batasannya, ini Claude Code yang sama dengan kotak di sekelilingnya, jadi mesin virtual lokal atau container melakukan hal yang sama. Yang penting kotaknya, bukan mereknya.

Pengungkapan: Kosuke memberi kami akses gratis ke paket teratasnya. Masukkan kode AIDIVE2026 di kolom "Promo code" tepat setelah mendaftar dan kamu mendapat kredit tiga puluh dolar, bukan sepuluh dolar seperti biasa.

Aturan kedua adalah apa yang sebenarnya kamu katakan pada REA. Kalau kamu hanya bilang "audit app-ku", skill REA berhenti dan bertanya app yang mana.

REA juga tidak pernah membuka browser sendiri, jadi kamu menjalankannya dengan debug port, pintu yang memungkinkan sebuah tool melihat semua yang dilakukan halaman. Atur dengan urutan ini:

1. Biarkan debug port di loopback, alamat yang hanya bisa dijangkau mesinmu sendiri, dan beri browser profil baru.
2. Blokir setiap request write sebelum halaman apa pun dimuat, sehingga audit bisa membaca situsmu tetapi tidak bisa mengirim form atau mengubah apa pun.
3. Baru setelah itu beri REA halaman persis yang ingin kamu suruh baca.

Di prompt kami, kami menyebut dua halaman klub gratis kami dan menulis satu aturan dengan kata-kata sederhana: jangan pernah kirim write ke situs live. Itu penting, karena form di halaman itu mengisi mailing list sungguhan dengan orang sungguhan di dalamnya. Agen menganggap serius aturan itu dan menulis guard kecilnya sendiri yang meloloskan read dan menghentikan semuanya. Selama audit, guard itu menahan enam percobaan dari skrip analytics, dan tidak satu pun request sampai ke form pendaftaran kami.

REA lalu mengerjakan bagiannya: memeriksa tiap halaman, membaca tiap bundle, mengambil screenshot, dan mengekspor skrip ke luar repo.

Batasannya, REA hanya melihat apa yang dimuat saat ia terpasang, jadi apa pun yang terjadi sebelumnya tetap menjadi unknown di laporan. Meski begitu, kamu kini punya laporan tentang aplikasi live-mu sendiri, yang ditulis tanpa menyentuh sedikit pun datanya.

Aturan ketiga adalah memilah sebelum memperbaiki. Laporan seperti ini penuh baris yang mengkhawatirkan dan kamu akan ingin memperbaiki semuanya sekaligus.

Skill REA sendiri meminta setiap kesimpulan ditandai sebagai observation, inference, atau unknown, lengkap dengan evidence ID. Artinya: apa yang dilihat, apa yang ditebak, dan apa yang tidak bisa dilihat, dan evidence ID adalah tanda terima yang bisa kamu periksa. Pilah setiap temuan dengan cara itu lebih dulu, hanya dari sudut pandang orang luar, dan commit versi itu sebelum membuka satu pun file source. Baru kemudian baca source-mu dan tandai tiap baris sebagai kebocoran nyata, by design, atau false positive.

Laporan kami berisi lima belas temuan:

Temuan	Yang dilihat REA	Putusan kami
Endpoint pendaftaran	Tanpa batas dan tanpa pengecekan situs mana yang memanggil, jadi situs mana pun bisa membuat browser pengunjung mendaftarkan alamat apa pun ke list kami	Kebocoran nyata, yang terburuk
Email gate di paket gratis	Seluruh paket sudah ada di halaman yang kamu muat; satu baris di konsol browser menghapus gate, atau mode baca menampilkan teksnya	By design
Source map, key, cookie	Tidak ada di bundle, dan tidak ada cookie di mana pun	Kabar baik

Gate itu by design karena paketnya memang sengaja gratis, dan kode kami sendiri menyatakan form yang rusak tidak boleh menyembunyikan halaman gratis.

Batasannya adalah kolom unknown. REA tidak bisa melihat apa yang dilakukan servermu, jadi baris-baris itu kamu putuskan dengan membaca kode servermu.

Aturan keempat menyangkut apa yang dibawa bundle-mu, karena satu file pengaturan bersama bisa sampai ke setiap pengunjung tanpa kamu sadari.

Begini terjadinya. Kamu mengimpor config di satu helper, dan dua komponen interaktif kecil memakai helper itu. Bundler, tool yang mengemas kodemu menjadi file yang diunduh browser, tidak bisa tahu key mana yang dibutuhkan, jadi semuanya dikirim.

Itulah yang ditemukan REA di JavaScript kami. Seluruh config situs kami ada dalam satu file, lengkap dengan ID mailing list, folder build, dan batas bot yang menjawab komentar di video kami. Bahkan tertulis berapa balasan yang dikirim bot itu per hari, seratus, dan berapa error yang memicu saklar pengamannya. Dua komponen yang menariknya masuk hanya membaca nama situs dan daftar bahasa.

Aturannya: cari key config-mu sendiri di JavaScript yang sudah dirilis, dan beri komponen client hanya field yang mereka baca. Di sandbox kami, agen memecah config menjadi versi browser mungil yang hanya berisi field itu, dan sisanya tetap di server. Agen juga menambahkan langkah build yang gagal kalau key server muncul lagi di file yang dirilis, sehingga kamu tidak bisa mundur lagi.

Tidak ada yang berupa password, tetapi apa pun di file itu bersifat publik, jadi rahasiamu hanya boleh ada di variabel server.

Aturan kelima memperbaiki kebocoran nyata kami, dan berlaku setiap kali kamu punya form publik yang memanggil layanan berbayar: list email-mu, model AI-mu, atau gateway pesan teks-mu. Kamu memanggilnya lewat fungsi server kecil yang kamu tulis dalam satu sore. Punya kami menerima email dan langsung meneruskannya ke mailing list, dan situs lain mana pun bisa membuat browser pengunjung mengirimkannya.

Daftar periksa dunia keamanan sendiri menyatakannya terang: access control-mu hanya bekerja di kode yang tidak bisa diubah penyerang, artinya servermu. Jadi pasang rem pada setiap endpoint seperti itu:

• Pengecekan Origin. Header Origin adalah cap yang ditaruh browser pada request untuk menyatakan situs mana yang mengirim, jadi form dari situs lain ditolak.
• Rate limit. Batas berapa banyak request yang bisa dikirim satu pengunjung dalam jendela waktu singkat.
• Consent dicek di server. Kotak yang kamu centang benar-benar ikut dalam request.

Di sandbox kami, agen menulis semuanya ke dalam Worker kami, fungsi kecil yang berjalan di depan halamanmu saat dikunjungi. Agen lalu mengujinya terhadap layanan mailing palsu, bukan yang asli, dan setiap request ditolak tepat di tempat yang seharusnya. Kirim dari situs yang salah, kamu ditolak. Request keenammu dalam semenit juga ditolak, dan tanpa consent kamu ditolak.

Batasannya, skrip bisa memalsukan cap Origin, dan rate limit menghitung per lokasi, jadi penyelesaian sebenarnya adalah konfirmasi ganda lewat email.

Aturan keenam dan terakhir adalah membuktikan perbaikannya, karena deretan centang hijau persis saat kamu berhenti memeriksa. Seorang developer yang menguji REA pada aplikasi desktop menulis di HackerNoon bahwa REA melewatkan entry point yang sebenarnya ada di aplikasi itu.

Jadi jalankan ulang langkah REA yang sama pada build yang sudah diperbaiki, cek setiap perbaikan dengan tangan dari terminal, dan baru setelah itu buka pull request.

Pada build yang sudah diperbaiki, request yang dulu lolos lewat form pendaftaran kami sekarang ditolak. Key server kami hilang dari setiap file yang dirilis, header keamanan terpasang, dan tes Worker berubah dari gagal menjadi lulus. Gate di paket gratis kami masih terbuka, dan itu keputusan kami, dan laporannya mencatatnya di samping setiap baris.

Agen lalu membuka pull request. Laporannya ada di dalamnya hanya karena kami memintanya di prompt. Daftar periksa pengujian yang dibuat Kosuke tetap berada di dalam sesi, tanpa ada yang diposting di pull request itu sendiri. Kalau reviewer-mu hanya membaca GitHub, taruh sendiri laporan sebelum dan sesudah di pull request.

Setelah itu kami membawa perubahan yang sama ke kode kami sendiri, dan perubahan itu tayang pada deploy situs kami berikutnya.

Seluruh prosesnya adalah REA diarahkan ke situs live kami sendiri dari sandbox sekali pakai, setiap temuan dipilah, kebocoran nyata diperbaiki, diaudit lagi, dan dirilis sebagai pull request. Temuan yang membenarkan semuanya adalah yang pertama: situs mana pun bisa mengisi form pendaftaran kami dengan alamat siapa pun.

Jalankan audit ini sebelum meluncurkan apa pun yang punya form publik atau layanan berbayar di belakangnya, dan jalankan lagi setiap kali kamu mengubah apa yang dirilis. Jangan jalankan pada software yang bukan milikmu, karena disclaimer REA sendiri membatasinya pada software milikmu atau yang kamu berwenang memeriksanya. Dan ini tidak pernah menggantikan membaca kode servermu, karena di sanalah unknown berada.

Kalau kamu hanya memegang satu aturan, pegang yang ini: jalankan pada dirimu sendiri, di dalam kotak, dan perbaiki hanya yang sudah kamu pilah.

Prompt persisnya, tabel triage, dan perbaikan Worker yang kami rilis ada di kit gratis untuk video ini.