Tentu — saya pertahankan struktur dan maknanya, tetapi dibuat natural dalam Bahasa Indonesia.

Apa yang Terjadi

UpGuard menganalisis sekitar 300.000 domain yang terindikasi menggunakan Supabase dan menemukan 16.326 database dengan setidaknya satu tabel yang dapat dibaca. Lebih dari separuh database tersebut diduga mengekspos data pribadi (PII), sementara sebagian kecil lainnya juga mengekspos password atau token autentikasi.

Data yang dilaporkan bocor mencakup nama, nomor telepon, alamat email, nomor plat kendaraan, riwayat kunjungan, pesan pribadi, dan dalam beberapa kasus password dalam bentuk plaintext. Peneliti juga menyebutkan bahwa sejumlah kecil database mungkin berisi data kartu kredit.

Mengapa Ini Penting?

Eksposur seperti ini berbahaya karena PII dapat digunakan untuk phishing, penipuan, dan pencurian identitas. Sementara itu, password dan token autentikasi dapat digunakan untuk mengambil alih akun. Risikonya juga tidak terbatas pada satu aplikasi, karena kredensial yang bocor mungkin digunakan kembali pada layanan lain.

Insiden ini juga menjadi pengingat bahwa masalah keamanan cloud sering terjadi pada lapisan konfigurasi. Sebuah database dapat berfungsi sepenuhnya seperti biasa, tetapi tetap dapat dibaca secara publik jika kebijakan aksesnya terlalu longgar atau tidak dikonfigurasi.

Bagaimana Ini Bisa Terjadi?

Peneliti mengaitkan eksposur tersebut dengan konfigurasi keamanan yang lemah, terutama row-level security (RLS) yang tidak diterapkan atau memiliki kebijakan yang terlalu permisif, serta penggunaan public key yang tidak tepat.

Mereka juga mencatat bahwa beberapa kasus mungkin melibatkan pengembangan dengan bantuan AI, yang dapat meningkatkan risiko konfigurasi tidak aman diterapkan dengan cepat tanpa pemeriksaan keamanan yang memadai.

Dokumentasi Supabase menekankan bahwa pengguna bertanggung jawab untuk mengamankan data mereka sendiri. Row-level security merupakan salah satu komponen penting untuk melindungi tabel yang dapat diakses melalui API.

Panduan Supabase untuk production juga merekomendasikan pemeriksaan kebijakan akses dan berbagai pengaturan keamanan sebelum aplikasi diluncurkan.

Pelajaran Keamanan

Tim yang menggunakan Supabase harus memastikan bahwa row-level security telah diaktifkan dan diuji dengan benar pada setiap tabel sensitif.

Hindari menyimpan password dalam bentuk plaintext, minimalkan penyimpanan PII yang tidak diperlukan, dan segera lakukan rotasi terhadap token atau secret yang terlanjur terekspos.

Salah satu pemeriksaan praktis adalah menguji setiap tabel seolah-olah Anda adalah pengguna yang belum login, kemudian memastikan bahwa tidak ada data sensitif yang dapat dibaca.

Jika sebuah tabel tidak seharusnya dapat diakses publik, jangan mengandalkan pengaturan default untuk menjaga tabel tersebut tetap privat.

Bagaimana Cara Mencegahnya?

Aktifkan Row Level Security (RLS) pada setiap tabel yang berisi data sensitif dan buat kebijakan eksplisit untuk setiap operasi yang memang diizinkan.

Dokumentasi Supabase menjelaskan bahwa tabel tanpa RLS dan kebijakan yang tepat dapat menjadi dapat diakses dengan cara yang tidak diinginkan.

Simpan kredensial rahasia hanya di sisi server, terutama service role key atau kredensial dengan hak akses tinggi lainnya. Kredensial tersebut dapat melewati RLS dan tidak boleh diekspos dalam kode frontend.

Simpan secret secara aman, segera lakukan rotasi terhadap token atau password yang bocor, dan batalkan sesi pengguna jika terdapat indikasi bahwa kredensial telah terekspos.

Uji database seolah-olah Anda adalah penyerang yang belum login, kemudian uji kembali sebagai pengguna biasa untuk memastikan hanya data yang memang seharusnya dapat diakses yang terlihat.

Supabase juga merekomendasikan penggunaan production checklist, meninjau temuan dari Security Advisor, serta memeriksa grants dan policies sebelum menerapkan perubahan ke production.

Checklist Praktis

  • Aktifkan RLS pada semua tabel yang dapat diakses melalui API.
  • Buat kebijakan dengan prinsip least privilege untuk operasi SELECT, INSERT, UPDATE, dan DELETE.
  • Simpan service role key dan secret key hanya di backend.
  • Hindari menyimpan password dalam bentuk plaintext dan kurangi PII yang tidak diperlukan.
  • Uji akses sebagai pengguna anonim dan pengguna yang sudah login.
  • Tinjau production checklist dan security checklist sebelum aplikasi diluncurkan.
  • Rotasi token yang bocor, reset password, dan batalkan sesi jika diperlukan.

Kesimpulan

Skala temuan ini menunjukkan betapa cepatnya data sensitif dapat menjadi publik ketika izin akses database tidak dikonfigurasi dengan benar.

RLS yang kuat, pengelolaan secret yang tepat, dan pengujian akses secara rutin merupakan pertahanan utama untuk mencegah kesalahan konfigurasi berubah menjadi insiden keamanan.

Kembali ke halaman utama