FixVibe

// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true dijelaskan: apa yang dilakukannya dan cara memperbaikinya

<code>allow read, write: if true;</code> adalah miskonfigurasi Firebase paling umum dalam produksi. Itu adalah default mode test yang disarankan Firebase Console ketika Anda membuat database baru, aturan yang AI coding tools regenerasi dari dokumentasi, dan aturan yang membuka seluruh database Firestore Anda kepada siapa saja di internet. Artikel ini menjelaskan sintaks secara tepat, menunjukkan apa yang dilihat penyerang ketika aturan ini aktif, dan memberi Anda empat pengganti yang semakin ketat yang cocok untuk berbagai kasus penggunaan.

Sintaks, baris demi baris

Dokumen aturan mode test Firestore lengkap adalah enam baris:

firebase
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Diuraikan:

  • rules_version = '2'; memilih engine aturan v2 (saat ini). Aturan v1 yang lebih lama sudah usang.
  • service cloud.firestore membatasi blok ke Firestore. Realtime Database menggunakan sintaks berbasis JSON yang berbeda; Cloud Storage menggunakan service firebase.storage.
  • match /databases/{database}/documents mengikat database khusus (default) (sebagian besar proyek hanya memiliki satu).
  • match /{document=**} adalah wildcard rekursif. ** mencocokkan path apa pun dengan kedalaman apa pun. Dikombinasikan dengan {document}, ini menangkap setiap dokumen di setiap koleksi — satu klausa match yang mengatur seluruh database.
  • allow read, write: if true; adalah body aturan. Baik read maupun write diizinkan; kondisi if true adalah, well, selalu benar. read mencakup operasi get dan list; write mencakup create, update, dan delete.

Efek bersih: klien apa pun dengan project ID Firebase dan SDK yang tepat dapat membaca atau menulis dokumen apa pun di koleksi apa pun. Autentikasi tidak diperlukan. Rate limit tidak diberlakukan.

Mengapa Firebase mengirimkan ini sebagai default

Firebase ingin Anda menulis kode dalam 30 detik pertama setelah membuat proyek. Alternatifnya — membuat Anda menulis aturan yang benar sebelum baca atau tulis bekerja — akan memblokir onboarding. Jadi Console menawarkan dua opsi saat Anda membuat database: Production mode (tolak semuanya, Anda menulis aturan) atau Test mode (izinkan semuanya selama 30 hari). Sebagian besar pengembang mengklik mode test, lalu lupa untuk kembali. Proyek lama memiliki timer 30 hari; proyek saat ini memiliki aturan if true tanpa batas tanpa kadaluarsa otomatis.

Masalah struktural: AI coding tools dilatih pada dokumentasi, tutorial, dan jawaban Stack Overflow yang menunjukkan aturan mode test. Ketika Anda meminta Cursor atau Claude Code "bagaimana cara menyiapkan Firebase," jawabannya sering mencakup blok allow read, write: if true yang persis seolah-olah itu adalah aturan produksi. AI tidak tahu — dan tidak diminta untuk tahu — bahwa aturan ini tidak aman untuk produksi.

Apa yang dilihat penyerang

Secara konkret, penyerang yang tahu project ID Firebase Anda (dapat diekstrak dari bundle aplikasi yang ter-deploy dalam 30 detik) dan menjalankan hal berikut dapat membuat daftar setiap dokumen di setiap koleksi:

Satu request curl tidak terautentikasi cukup untuk mengenumerasi setiap koleksi. Lihat blok yang disorot di bawah.

bash
curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Response adalah daftar lengkap koleksi tingkat atas. Untuk setiap koleksi, request kedua mengembalikan dokumen. Tidak ada rate limit pada path ini karena aturan if true menerima lalu lintas anonim. Kami telah melihat database Firebase dengan jutaan dokumen dienumerasi dalam waktu kurang dari satu jam.

Pada path tulis: satu POST dengan {fields} membuat dokumen baru. Penyerang dapat mencemari koleksi Anda dengan sampah, merusak halaman yang menghadap user yang membaca dari Firestore, atau menggunakan database Anda sebagai broker pesan gratis — tagihan penggunaan Anda meroket, Anda menyelidiki, tagihan menjelaskan masalah.

Empat pengganti yang aman untuk produksi

Pilih pengganti yang cocok dengan model data aplikasi Anda. Keempatnya mengasumsikan Anda memiliki autentikasi user (Firebase Auth atau provider apa pun yang menerbitkan token Firebase ID):

Opsi 1: Dokumen milik user

Pola SaaS paling umum. Dokumen hidup di bawah /users/{userId}/... dan hanya pemilik yang dapat menyentuhnya. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase
match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Opsi 2: Field pemilik di setiap dokumen

Ketika dokumen hidup dalam koleksi datar (tidak bersarang di bawah user ID), simpan field owner_uid dan periksa. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase
match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Opsi 3: Isolasi org multi-tenant

Untuk B2B SaaS dengan data berlingkup org. Simpan field org_id pada setiap dokumen dan periksa terhadap custom claim user. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Memerlukan pengaturan custom claim selama sign-up via Firebase Admin SDK.

firebase
allow read, write: if request.auth.token.org_id == resource.data.org_id;

Opsi 4: Konten publik hanya-baca

Untuk konten pemasaran, profil publik, katalog produk — apa pun yang sungguh-sungguh dapat dibaca publik tetapi hanya admin yang dapat menulis. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Custom claim admin hanya diatur pada akun admin.

firebase
match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Query audit cepat

Sebelum memperbaiki, periksa apakah if true benar-benar aktif. Buka Firebase Console → Firestore → Rules dan cari if true. Jika Anda menemukannya di mana pun di luar komentar, Anda memiliki temuan aturan terbuka. Simulator Rules di UI yang sama memungkinkan Anda memutar ulang request penyerang secara lokal — tempel GET /users/somebody anonim dan konfirmasi simulator mengembalikan Allowed.

Konfirmasi eksternal: jalankan scan FixVibe terhadap URL produksi Anda. Check baas.firebase-rules menyondir aturan Firestore, Realtime Database, dan Storage Anda dan melaporkan temuan yang sama yang akan ditemukan penyerang — independen dari apa yang ditampilkan Firebase Console.

Pertanyaan yang sering diajukan

Apa perbedaan antara <code>if true</code> dan <code>if request.auth != null</code>?

if true mengizinkan akses anonim — siapa saja di internet. if request.auth != null memerlukan user yang masuk apa pun, yang lebih baik tetapi masih salah: setiap user aplikasi Anda dapat membaca data setiap user lain. Aturan produksi harus dibatasi ke user atau org spesifik via request.auth.uid == resource.data.owner_uid atau serupa.

Apakah Firebase pernah secara otomatis mengkadaluarsakan aturan <code>if true</code>?

Proyek lama (pra-2023) memiliki timer 30 hari yang mengonversi aturan if true ke if false. Proyek saat ini tidak — aturan persisten tanpa batas waktu hingga diganti secara manual. Jika Anda membuat proyek Anda sebelum 2023 dan aturan Anda terlihat baik-baik saja, periksa dua kali: timer mungkin telah membaliknya ke if false, yang memblokir aplikasi Anda sendiri.

Dapatkah saya menggunakan pemeriksaan timestamp tanggal masa depan sebagai pengaman?

Tidak — kondisi timestamp bukan kontrol keamanan. Itu mengkadaluarsakan aturan terbuka pada tanggal masa depan, yang berarti hingga tanggal itu penyerang memiliki akses penuh. Dan Anda akan lupa tanggalnya. Ganti if true dengan aturan berlingkup auth, bukan yang dibatasi waktu.

Bagaimana jika aplikasi saya sungguh-sungguh dapat dibaca publik (blog, katalog produk)?

Maka secara eksplisit tulis allow read: if true; allow write: if false; hanya pada koleksi publik — tidak pada setiap koleksi di database Anda. Gunakan klausa match terpisah per koleksi dan tidak pernah gunakan wildcard rekursif {document=**} pada aturan yang dapat ditulis.

Langkah berikutnya

Jalankan scan FixVibe terhadap URL produksi Anda — check baas.firebase-rules mengonfirmasi apakah if true saat ini dapat dieksploitasi dari internet publik. Untuk mekanisme scanner dan deteksi paralel untuk Realtime Database dan Storage, lihat Scanner aturan Firebase. Untuk kelas miskonfigurasi setara di Supabase, baca Scanner RLS Supabase.

// scan permukaan baas anda

Temukan tabel terbuka itu sebelum orang lain menemukannya.

Masukkan URL produksi. FixVibe mengenumerasi penyedia BaaS yang berkomunikasi dengan aplikasi Anda, mengidentifikasi endpoint publiknya, dan melaporkan apa yang dapat dibaca atau ditulis oleh klien yang tidak terautentikasi. Gratis, tanpa instalasi, tanpa kartu.

  • Tier gratis — 3 scan / bulan, tanpa kartu untuk pendaftaran.
  • Fingerprinting BaaS pasif — tidak perlu verifikasi domain.
  • Supabase, Firebase, Clerk, Auth0, Appwrite, dan lainnya.
  • Prompt perbaikan AI di setiap temuan — tempel kembali ke Cursor / Claude Code.
Jalankan scan BaaS gratis →

tidak perlu pendaftaran

Firebase allow read, write: if true dijelaskan: apa yang dilakukannya dan cara memperbaikinya — Docs · FixVibe