Banyak pengembang yang panik saat pertama kali melihat pesan error "new row violates row-level security policy" muncul di konsol aplikasi mereka. Kesan pertama sering kali mengarah pada kecemasan apakah data bocor atau konfigurasi database rusak. Padahal, menurut analisis teknis terbaru, kesalahan ini justru merupakan indikasi positif bahwa Row Level Security (RLS) Supabase sedang aktif dan menolak akses secara default — perilaku yang seharusnya diinginkan dalam arsitektur keamanan modern.
Supabase, platform backend-as-a-service berbasis PostgreSQL yang populer di kalangan pengembang Indonesia, menerapkan filosofi "deny by default" pada RLS. Artinya, setiap operasi baca, tulis, ubah, atau hapus akan ditolak kecuali ada kebijakan eksplisit yang mengizinkannya. Kondisi berbahaya justru terjadi ketika RLS dinonaktifkan — tabel menjadi terbuka bagi siapa saja yang memiliki anon key, menciptakan celah keamanan nomor satu yang sering dieksploitasi.
Tiga penyebab utama penolakan penulisan data telah diidentifikasi. Pertama, tidak adanya kebijakan INSERT sama sekali — pengembang mengaktifkan RLS dan membuat policy SELECT, tetapi lupa menambahkan policy untuk operasi penulisan. Kedua, ketidaksesuaian nilai user_id — kebijakan ada dengan kondisi `user_id = auth.uid()`, namun klien mengirimkan baris tanpa mengisi user_id (menjadi null) atau mengisi dengan ID pengguna lain. Ketiga, permintaan tidak terautentikasi — aplikasi berjalan dengan anon key tanpa sesi aktif, sehingga `auth.uid()` bernilai null dan kondisi validasi tidak akan pernah terpenuhi.
Solusi teknisnya relatif sederhana namun memerlukan pemahaman yang tepat. Dibutuhkan sebuah policy INSERT yang mengizinkan pengguna terautentikasi menulis baris milik mereka sendiri, dikombinasikan dengan pengaturan default server-side untuk kolom user_id. Kueri SQL yang direkomendasikan mencakup pembuatan policy dengan klausa `WITH CHECK (user_id = (select auth.uid()))` serta perintah `ALTER TABLE` untuk menetapkan default kolom user_id secara otomatis ke `auth.uid()` pada sisi server.
Perbedaan mendasar antara `USING` dan `WITH CHECK` sering menjadi sumber kebingungan. Klausa `USING` berfungsi memfilter baris yang sudah ada — menentukan baris mana yang terlihat atau dapat disentuh oleh pengguna. Sementara `WITH CHECK` memvalidasi baris baru saat operasi INSERT atau UPDATE. Untuk kasus penolakan penulisan data baru, `WITH CHECK` adalah yang menentukan apakah operasi diizinkan atau ditolak.
Satu jebakan klasik yang sering mengecoh pengembang: kueri yang dijalankan melalui SQL Editor dashboard Supabase akan berhasil, tetapi gagal saat dieksekusi dari aplikasi. Hal ini karena SQL Editor berjalan dengan peran privilegiase yang melewati RLS, sedangkan aplikasi berjalan sebagai peran `authenticated` atau `anon` yang tunduk pada aturan RLS. Oleh karena itu, pengujian penulisan data harus dilakukan melalui klien aplikasi sesungguhnya dengan pengguna yang sudah login.
Di ekosistem pengembangan Indonesia, di mana Supabase semakin diminati sebagai alternatif Firebase yang lebih terbuka dan berbasis PostgreSQL, pemahaman ini krusial. Banyak startup lokal dan pengembang freelance yang bermigrasi ke Supabase untuk mengurangi ketergantungan vendor dan memanfaatkan kekuatan SQL penuh. Kesalahan konfigurasi RLS yang tidak disengaja dapat mengekspos data pengguna — nama, email, hingga transaksi — kepada publik, melanggar UU Perlindungan Data Pribadi (UU PDP) yang baru berlaku penuh sejak Oktober 2024.
Kendati dokumentasi resmi Supabase sudah cukup lengkap, kurva pembelajaran RLS tetap curam bagi pengembang yang terbiasa dengan database tradisional tanpa keamanan tingkat baris. Komunitas pengembang Indonesia di grup seperti Supabase Indonesia di Discord dan forum lokal sering membahas kasus serupa. Berbagi pola policy standar — seperti policy "owner inserts own" dan "owner updates own" — dapat mempercepat onboarding tim baru dan mengurangi risiko kesalahan konfigurasi.
Mengakhiri kebiasaan menonaktifkan RLS demi "mempercepat development" adalah langkah matang yang harus ditekankan. Dalam jangka pendek, menonaktifkan RLS memang memungkinkan prototipe berjalan lancar. Namun di lingkungan produksi, praktik ini setara dengan meninggalkan pintu depan rumah terbuka lebar. Biaya perbaikan kebocoran data — baik finansial maupun reputasional — jauh lebih mahal dibandingkan waktu yang dibutuhkan untuk menulis policy yang benar sejak awal.
Ke depan, Supabase terus memperbaiki pengalaman pengembang dengan fitur seperti Policy Generator di dashboard dan peringatan visual saat RLS dinonaktifkan. Pengembang Indonesia sebaiknya memanfaatkan alat bantu tersebut, serta mengadopsi praktik "test as authenticated user" sebagai bagian standar alur kerja CI/CD. Keamanan bukan fitur tambahan, melainkan fondasi yang harus dibangun sebelum baris kode pertama aplikasi dieksekusi.