// docs / baas security / firebase rules scanner
Scanner aturan Firebase: temukan aturan Firestore, Realtime Database, dan Storage yang terbuka
Aplikasi Firebase gagal dalam keamanan dengan satu cara yang konsisten: aturan allow read, write: if true; yang tersisa dari quickstart mode test, tidak pernah diganti sebelum produksi. AI coding tools menghasilkan aturan-aturan ini verbatim dari contoh dokumentasi dan jarang meminta pengembang untuk mengeraskannya. Artikel ini menunjukkan bagaimana scanner aturan Firebase mendeteksi aturan terbuka di Firestore, Realtime Database, dan Cloud Storage dari luar proyek β dan cara memperbaiki apa yang ditemukannya.
Bagaimana scanner menemukan aturan Firebase yang terbuka
Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:
- Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
- Realtime Database. FixVibe reports a database whose data anonymous visitors can read β often the whole tree at once.
- Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.
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;
}Basis Data Waktu Nyata
{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }. Wildcard $uid menangkap segmen path untuk perbandingan.
{
"rules": {
"users": {
"$uid": {
".read": "$uid === auth.uid",
".write": "$uid === auth.uid"
}
}
}
}Penyimpanan Awan
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 rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan β the open-rules finding should clear.
firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storageBagaimana 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
Apakah scanner membaca atau memodifikasi data Firestore saya?
Scan pasif mengeluarkan paling banyak satu baca anonim per layanan untuk mengonfirmasi apakah aturan mengizinkannya. Scanner mencatat bentuk response dan keberadaan data β ia tidak melakukan paginasi, tidak mengenumerasi dokumen, dan tidak menulis. Sondir tulis diperketat di balik verifikasi kepemilikan domain dan tidak pernah berjalan terhadap target yang belum diverifikasi.
Bagaimana jika proyek Firebase saya menggunakan App Check?
App Check menolak request yang tidak terautentikasi dengan 403. Scanner tanpa token App Check akan melihat 403 pada setiap sondir β yang merupakan hasil yang benar. App Check bukan pengganti untuk kebenaran aturan (token App Check yang dicuri ditambah aturan terbuka tetap membocorkan data), tetapi ia memblokir scan eksternal oportunistik.
Dapatkah scanner mendeteksi miskonfigurasi aturan parsial (baca terbuka, tulis tertutup)?
Yes. Open read access and open write access are reported as separate findings, because data exfiltration and data manipulation are separate risks.
Apakah ini bekerja untuk aplikasi Firebase yang di-deploy di bawah domain kustom?
Ya. Scanner mengekstrak project ID Firebase dari bundle yang ter-deploy, bukan dari domain. Domain kustom, subdomain app.web.app, dan aplikasi Firebase self-hosted semuanya bekerja dengan cara yang sama selama bundle JavaScript dapat dijangkau.
Langkah berikutnya
Run a free FixVibe scan against your production URL β the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.
