Scanner aturan Firebase: temukan aturan Firestore, Realtime Database, dan Storage yang terbuka

Bagaimana scanner menemukan aturan Firebase yang terbuka

Layanan Firebase mengekspos bentuk URL yang terkenal dan dapat diprediksi. Scanner tanpa kredensial dapat menyondir setiap dari mereka dan mengamati apakah baca anonim berhasil. Check baas.firebase-rules FixVibe berjalan dalam tiga sondir independen — satu per layanan Firebase:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. Scanner menyondir https://[project-id]-default-rtdb.firebaseio.com/.json. Jika root dapat dibaca secara anonim, response adalah seluruh pohon database sebagai JSON. Uji yang lebih konservatif men-query .json?shallow=true, yang mengembalikan kunci tingkat atas saja — tetap merupakan temuan dengan cara mana pun.
• Cloud Storage. Scanner men-query https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Jika response menampilkan daftar nama file tanpa autentikasi, bucket dapat di-list anonim. Storage yang dapat di-list adalah temuan bahkan ketika unduhan file individu ditolak — penyerang mengenumerasi bucket untuk menemukan nama file yang dapat ditebak.

Seperti apa footgun mode test sebenarnya

Dokumentasi quickstart Firebase mencakup salah satu blok aturan yang paling banyak disalin di internet:

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

Firebase dulu menambahkan kadaluarsa otomatis 30 hari pada aturan-aturan ini. Itu berubah: hari ini aturan persisten selamanya kecuali pengembang menggantinya. AI coding tools — terlatih pada tahun-tahun dokumentasi yang mencakup blok mode test — sering mengeluarkannya secara verbatim dan memberitahu pengembang "ini adalah aturan keamanan Anda." Itu bukan.

Varian lain yang muncul dalam produksi tetapi sama permisifnya:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• Varian dengan timestamp masa depan: aturan yang mengizinkan semuanya sampai tanggal yang jauh di masa depan. Tidak pernah benar-benar kadaluarsa (lihat blok yang disorot di atas).
• allow read: if true; allow write: if request.auth != null; — baca publik, setiap user terautentikasi dapat menulis.
• allow read, write: if request.auth != null; — setiap user yang masuk dapat membaca atau menulis dokumen apa pun, termasuk data user lain.

Apa yang harus dilakukan ketika scanner menemukan aturan terbuka

Aturan Firebase yang terbuka adalah keadaan darurat runtime. Perbaikannya berbentuk sama di ketiga layanan: batasi setiap aturan ke request.auth.uid terhadap field pemilik eksplisit. Setiap layanan memiliki sintaks aturannya sendiri:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. Pengikatan segmen path {userId} menjadi satu-satunya dokumen yang dapat disentuh user.

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Konvensi: simpan file di bawah users/[uid]/[filename] dan biarkan path menegakkan kepemilikan.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Deploy aturan via Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifikasi aturan baru ada di produksi dengan menjalankan kembali scan FixVibe — temuan baas.firebase-rules seharusnya hilang.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Bagaimana ini dibandingkan dengan tool bawaan Firebase

Firebase Console menunjukkan aturan saat ini tetapi tidak mengaudit terhadap perilaku runtime. Simulator Firebase Rules memungkinkan Anda menguji logika aturan terhadap request sintetis — berguna tapi lokal. Tidak ada tool yang memberi tahu Anda apa yang sebenarnya dikembalikan aturan produksi Anda kepada penyerang anonim di internet publik. Scanner eksternal seperti FixVibe (atau Burp Suite dengan konfigurasi manual) adalah satu-satunya yang menyondir dari sudut yang sama dengan penyerang. App Check milik Google sendiri memitigasi penyalahgunaan tetapi tidak menggantikan aturan yang dibatasi dengan benar.

Pertanyaan yang sering diajukan

Langkah berikutnya

Jalankan scan FixVibe gratis terhadap URL produksi Anda — check baas.firebase-rules dikirim di setiap paket dan menandai aturan terbuka di Firestore, Realtime Database, dan Cloud Storage. Untuk penjelasan lebih dalam tentang pola allow read, write: if true secara spesifik, lihat Firebase allow read, write: if true dijelaskan. Untuk tinjauan menyeluruh lintas Supabase, Firebase, Clerk, dan Auth0, baca Scanner miskonfigurasi BaaS.