Peneliti keamanan Romain Durieux baru‑baru ini mempublikasikan hasil pemindaian pasif terhadap 15 aplikasi publik yang dibangun menggunakan platform Lovable. Dengan menggunakan alat gratis bernama sealdy.dev, ia memeriksa apa yang secara otomatis diunduh oleh browser ketika halaman dimuat, tanpa melakukan eksploitasi aktif. Dari 15 aplikasi yang diperiksa, 6 di antaranya (40%) memuat basis data Supabase langsung di sisi klien, sehingga kunci API publik terlihat di sumber halaman. Meskipun hal ini dapat diterima jika pengaturan Row‑Level Security (RLS) dikonfigurasi dengan benar, satu pengaturan yang salah dapat mengubahnya menjadi "siapa pun dapat membaca seluruh tabel". Selain itu, 14 dari 15 aplikasi tidak memiliki kebijakan Content‑Security‑Policy (CSP), sebuah penguat keamanan dasar yang dapat mencegah injeksi skrip.
Masalah ini bukan sekadar teori. Dua aplikasi yang diaudit dengan izin pemiliknya menunjukkan kebocoran data yang serius. Aplikasi sosial pertama membocorkan tabel profil yang berisi nama pengguna, kota, dan hash kata sandi, sehingga dapat diakses oleh pengunjung yang belum masuk. Kebocoran ini diperbaiki dalam waktu satu hari. Aplikasi pembelajaran berbayar kedua mengekspos 155 lembar studi berbayar dan 4.872 jawaban, yaitu seluruh katalog berbayar, yang dapat diakses oleh siapa pun tanpa akun atau langganan. Paywall hanya diterapkan di front‑end, sementara database tetap melayani semua data ke semua orang tanpa autentikasi.
Durieux menekankan bahwa memuat Supabase di browser itu sendiri bukan kesalahan; masalah sebenarnya adalah kurangnya penegakan akses di tingkat basis data. RLS yang tidak diterapkan memungkinkan aplikasi untuk memberikan akses baca universal, dan alat yang digunakan untuk membangun aplikasi tersebut tidak akan memperingatkan pengembang tentang masalah ini. Bagi siapa pun yang membangun produk di Lovable, Bolt, atau Replit yang memiliki pengguna nyata atau pengguna berbayar, pemeriksaan cepat selama 60 detik tentang apa yang dapat diakses oleh orang asing dapat menghemat banyak masalah.
Pengguna yang khawatir dapat menjalankan alat pindai pasif milik Durieux di sealdy.dev. Alat ini tidak memerlukan pendaftaran dan memberikan gambaran cepat tentang apakah aplikasi mengekspos data sensitif secara tidak sengaja. Selain itu, ia menyambut pertanyaan tentang cara kerja kebocoran RLS dan langkah‑langkah untuk menguncinya.
Praktik terbaik keamanan saat ini mencakup penerapan RLS yang ketat, penambahan kebijakan CSP yang kuat, memindahkan kunci API ke endpoint server‑side, dan melakukan audit keamanan secara berkala. Pengembang harus menganggap setiap bagian data yang dapat diakses secara publik sebagai potensi kebocoran dan menguji asumsi keamanan mereka. Dengan semakin banyaknya perusahaan Indonesia yang mengadopsi platform no‑code/low‑code seperti Lovable, kesadaran akan kerentanan ini menjadi semakin penting untuk melindungi pengguna dan menjaga kepercayaan.
Di pasar teknologi Indonesia, di mana startup sering kali mempercepat peluncuran produk untuk mendapatkan keunggulan kompetitif, temuan ini harus menjadi peringatan. Kebocoran data dapat merusak reputasi, menimbulkan sanksi kepatuhan (seperti yang diamanatkan oleh Undang‑Undang Perlindungan Data), dan menyebabkan kerugian finansial yang signifikan. Artikel ini menyoroti kebutuhan mendesak akan pendidikan keamanan yang lebih baik dan alat‑alat yang dapat membantu pengembang mendeteksi kebocoran secara proaktif sebelum kode tersebut digunakan oleh publik.
Secara keseluruhan, penelitian ini menunjukkan bahwa kenyamanan membangun aplikasi dengan basis data yang dimuat di browser memiliki risiko keamanan yang signifikan jika tidak dikendalikan dengan benar. Dengan menerapkan kontrol akses di sisi server, menerapkan CSP, dan melakukan pengujian keamanan secara rutin, pengembang dapat memanfaatkan kekuatan platform Lovable tanpa mengorbankan privasi pengguna atau integritas data.