Aturan akses Supabase dan Firebase (CWE-862): bagaimana Row Level Security yang hilang mengekspos data dan cara memperbaikinya

Konsep Kunci & Istilah

Kunci anon publik

Kunci anon Supabase dan konfigurasi web Firebase ikut di dalam bundle aplikasi, dan siapa pun bisa menyalinnya. Keduanya mengidentifikasi proyek, bukan pengguna, jadi bukan rahasia dan tidak bisa melindungi data sendirian.

Row Level Security (RLS)

Fitur PostgreSQL yang menyaring setiap kueri melalui kebijakan. Table Editor Supabase mengaktifkannya untuk tabel baru, tetapi tabel yang dibuat lewat SQL atau migrasi dimulai dengan RLS mati, dan hak akses default lalu membiarkan anon dan authenticated membaca dan mengubah setiap baris.

USING dan WITH CHECK

USING menentukan baris yang sudah ada mana yang boleh dilihat, diubah, atau dihapus pengguna; WITH CHECK menentukan baris baru atau yang diubah mana yang boleh ia tulis. Kebijakan yang hanya punya USING pada insert atau update membiarkan pengguna menulis baris untuk organisasi lain.

Kunci service_role

Kunci service_role melewati RLS sepenuhnya. Tempatnya hanya di server dan edge function, tidak pernah di browser atau aplikasi seluler.

Aturan Firestore mode uji

Proyek yang dimulai dalam mode uji mendapat aturan yang mengizinkan semua baca dan tulis hingga tanggal tertentu, dan banyak yang kemudian diubah menjadi allow read, write: if true. Aturan harus mencocokkan request.auth.uid dengan field pemilik dokumen.

Alur Serangan Langkah demi Langkah

Kode Sumber: Rentan vs Aman

-- migration.sql: RLS tidak pernah diaktifkan di tabel ini
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- kunci anon publik bisa membaca, mengubah, dan menghapus setiap baris
grant select, insert, update, delete on public.invoices to anon, authenticated;

-- migration.sql: RLS aktif, hak anon dicabut, satu kebijakan per perintah
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- setelah RLS aktif, tanpa kebijakan berarti tanpa akses
alter table public.invoices enable row level security;
revoke all on public.invoices from anon;

-- pengguna hanya melihat invoice organisasi tempat mereka bergabung
create policy "members read their org's invoices"
  on public.invoices for select to authenticated
  using (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

-- baris baru harus milik salah satu organisasi pengguna; tidak ada kebijakan update atau delete
create policy "members add invoices to their org"
  on public.invoices for insert to authenticated
  with check (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

Daftar Periksa Penguatan Sistem Rekayasa

• Aktifkan RLS di setiap tabel pada skema yang terekspos, dan gagalkan CI ketika select tablename from pg_tables where schemaname = 'public' and not rowsecurity mengembalikan baris apa pun.
• Tulis satu kebijakan per perintah, dibatasi to authenticated, dengan USING untuk pembacaan dan WITH CHECK untuk insert dan update; jangan buat kebijakan update dan delete yang tidak diperlukan.
• Cabut hak tabel dari anon jika pengguna anonim tidak punya alasan membaca, dan simpan kunci service_role hanya di lingkungan server.
• Aktifkan RLS juga pada tabel yang dibaca kebijakan Anda, seperti memberships, agar pengguna tidak bisa menambahkan dirinya ke organisasi lain.
• Uji dengan dua pengguna uji: pengguna A harus mendapat nol baris untuk organisasi pengguna B; untuk Firestore, jalankan tes unit aturan di emulator dengan @firebase/rules-unit-testing.

Sumber

• CWE-862: Missing Authorization
• Supabase docs — Row Level Security
• PostgreSQL docs — CREATE POLICY
• Firebase docs — Get started with Cloud Firestore Security Rules
• NVD — CVE-2025-48757 (missing Row Level Security in generated apps)