Apakah Supabase Aman untuk Produksi? Yang Menentukan Bukan

Banyak developer bertanya apakah Supabase aman untuk aplikasi produksi. Pertanyaan itu wajar. Supabase semakin populer karena cepat dipakai, punya autentikasi bawaan, dan database Postgres yang kuat. Namun keamanan Supabase bukan jawaban ya atau tidak. Platform ini memberi fondasi, tetapi aturan mainnya ditulis oleh Anda.

Kebocoran data di Supabase jarang terjadi karena server mereka diserang. Lebih sering, masalah muncul karena konfigurasi yang longgar. Tabel tanpa Row Level Security, anon key yang dipakai sembarangan, atau policy storage yang terlalu terbuka. Semua itu bukan bug platform. Itu celah yang dibuat tanpa sengaja oleh developer.

Artikel ini menjelaskan lapisan-lapisan yang menentukan jawaban atas pertanyaan apakah Supabase aman. Anda akan melihat perbedaan anon key dan service key, peran RLS, jalur storage dan RPC, lalu urutan pengujian yang bisa langsung dipraktikkan.

Anon Key vs Service Key: Dua Akses yang Sering Tertukar

Supabase memberikan dua jenis kunci API: anon key dan service key. Keduanya terlihat mirip, tetapi tingkat aksesnya sangat berbeda. Anon key dirancang untuk dipakai di sisi klien. Kunci ini tetap tunduk pada Row Level Security. Service key adalah kunci administratif yang melewati RLS sepenuhnya.

Kesalahan umum terjadi ketika developer menyimpan service key di environment variabel aplikasi frontend, lalu tanpa sadar memakainya di browser. Akibatnya, siapa pun yang membuka aplikasi bisa membaca seluruh isi database, termasuk data pengguna lain. Anon key tidak akan memberi akses sebanyak itu selama RLS aktif.

Cara membedakannya sederhana. Anon key boleh muncul di kode sisi klien. Service key hanya boleh dipakai di server, background job, atau script migrasi. Jika service key pernah terlihat di log browser, anggap kunci itu sudah bocor dan rotasi segera.

Row Level Security: Saklar Utama yang Harus Dinyalakan

Row Level Security atau RLS adalah fitur Postgres yang menentukan baris mana yang boleh dibaca atau diubah oleh pengguna tertentu. Tanpa RLS, tabel bersifat terbuka. Siapa pun yang memegang anon key bisa membaca semua isinya. RLS mengubah tabel menjadi berlapis aturan.

Supabase tidak mengaktifkan RLS secara paksa untuk semua tabel baru. Ini pilihan desain yang memberi fleksibilitas, tetapi juga menuntut kedisiplinan developer. Membuat tabel lalu lupa menyalakan RLS adalah kesalahan paling sering yang membuat data terbaca. AISG memeriksa pola ini secara statis dengan aturan AISG-RLS-001 (tabel tanpa ENABLE ROW LEVEL SECURITY). Hasilnya berupa kandidat temuan yang tetap perlu Anda verifikasi manual — bukan bukti exploit.

Setelah RLS aktif, Anda perlu menulis policy. Policy menentukan kondisi akses, misalnya pengguna hanya boleh membaca baris yang kolom user_id-nya sama dengan ID mereka. Policy ini tidak otomatis dibuat. Anda yang mendefinisikan aturannya.

Artikel terkait RLS Supabase: aplikasi bocor data tanpa error membahas lebih dalam tentang pola kegagalan ini. Intinya, aplikasi tetap berjalan normal, tidak ada error, tetapi data orang lain bisa diakses lewat permintaan API yang dimodifikasi.

Storage dan RPC: Pintu Lain Menuju Data Anda

Database bukan satu-satunya permukaan serangan. Supabase Storage menyimpan file yang diunggah pengguna. Setiap bucket storage punya policy sendiri. Bucket publik memang dirancang untuk dibaca siapa saja, seperti aset gambar di halaman web. Tetapi bucket pribadi perlu policy yang membatasi akses berdasarkan pemilik file.

Kesalahan umum terjadi ketika developer membuat bucket pribadi tetapi lupa menambahkan policy. Akibatnya, file pribadi bisa diakses lewat URL publik tanpa autentikasi. Ini bukan kerentanan Supabase. Ini konfigurasi yang belum selesai.

Fungsi RPC juga perlu perhatian. Fungsi Postgres yang dipanggil lewat Supabase RPC bisa menjalankan operasi dengan hak istimewa tertentu. Jika fungsi ditulis dengan SECURITY DEFINER, fungsi itu berjalan dengan hak pembuatnya, bukan hak pemanggilnya. Tanpa validasi parameter yang baik, RPC bisa menjadi celah untuk membaca data yang seharusnya tersembunyi.

Urutan Uji Keamanan Supabase Secara Praktis

Alih-alih bertanya terus apakah Supabase aman, lebih baik menjalankan pengujian sederhana. Urutan berikut bisa dilakukan tanpa alat khusus, cukup browser dan konsol Supabase.

1. Cek tabel tanpa RLS. Buka dashboard Supabase, lihat daftar tabel. Pastikan setiap tabel yang menyimpan data sensitif memiliki tanda RLS aktif. Tabel tanpa RLS berarti data bisa terbaca oleh siapa pun yang memegang anon key.
2. Uji baca dengan anon key. Salin anon key dari pengaturan proyek. Gunakan curl atau konsol browser untuk memanggil endpoint REST tabel. Coba baca baris dari tabel lain tanpa filter. Jika data keluar, RLS belum aktif atau policy terlalu longgar.
3. Uji endpoint storage. Ambil URL publik dari file di bucket pribadi. Buka di jendela penyamaran tanpa login. Jika file tampil, policy storage belum membatasi akses.
4. Uji RPC yang mengekspos data. Periksa daftar fungsi RPC di dashboard. Panggil fungsi yang membaca tabel lewat anon key. Lihat apakah fungsi itu mengembalikan data di luar batas yang seharusnya.
5. Rotasi kunci yang pernah terlihat. Jika anon key atau service key pernah muncul di riwayat git publik atau log browser, rotasi dari dashboard Supabase. Kunci yang bocor tidak bisa dianggap aman meskipun RLS sudah diperbaiki.

Kelima langkah ini memberi gambaran awal. Pemindaian otomatis seperti yang tersedia di AISG bisa membantu mempercepat deteksi, tetapi temuan pemindaian bersifat indikasi. Setiap temuan tetap perlu divalidasi manusia sebelum dianggap sebagai celah nyata.

Default Longgar Bukan Bug Platform

Anda tidak bisa menyalahkan Supabase jika tabel tanpa RLS bisa dibaca lewat anon key. Platform ini memang mengizinkan tabel dibuat tanpa RLS agar developer punya kendali penuh. Namun kendali penuh berarti tanggung jawab penuh. Default longgar bukan bug platform Anda; itu panggilan untuk menulis aturan lebih disiplin.

Artikel apakah vibe coding aman membahas pola serupa pada pendekatan pengembangan cepat. Kecepatan menulis kode sering kali mengorbankan validasi keamanan. Supabase mempercepat pembangunan aplikasi, tetapi kecepatan itu jangan sampai membuat RLS dan policy terlewat.

Kesimpulan

Jawaban atas pertanyaan apakah Supabase aman bergantung pada seberapa rapi Anda mengatur lapisan keamanannya. Anon key dan service key harus dipisahkan tegas. RLS harus aktif di semua tabel sensitif. Policy storage dan RPC perlu ditinjau ulang. Default yang longgar bukan tanda platform bermasalah, melainkan undangan untuk mengonfigurasi lebih hati-hati.

Jangan berhenti pada keyakinan bahwa platform sudah aman. Jalankan urutan uji di atas, periksa tabel tanpa RLS, uji baca dengan anon key, dan pastikan tidak ada celah yang terbuka. Keamanan Supabase adalah hasil kerja Anda, bukan fitur yang datang otomatis.