Firebase Rules Allow All: Bahaya dan Cara Menutupnya

Ada satu baris di Firebase yang paling sering menyelamatkan demo dan paling sering merusak produksi: allow read, write: if true;. Artinya sederhana. Siapa pun, termasuk orang tanpa akun, boleh membaca dan menulis ke database Anda. Tidak ada pemeriksaan identitas. Tidak ada pembatasan field. Selama proyek aktif dan konfigurasi klien tersedia di aplikasi, pintunya terbuka.

Pola firebase rules allow all bukan bug mesin. Firebase menjalankan apa pun yang Anda tulis. Justru karena itu, aturan longgar jarang terdeteksi: aplikasi berjalan normal, tidak ada error, tidak ada log merah, dan semua fitur terasa lancar. Kerusakannya baru terlihat saat ada orang lain yang memanfaatkannya.

Artikel ini membahas kenapa aturan longgar mudah tertinggal, cara menguji sendiri apakah proyek Anda sudah terbuka, pola aturan berbasis pemilik dokumen, dan batas pengujian manual maupun emulator.

Apa yang sebenarnya dibuka oleh allow all

Firebase punya beberapa produk dengan bahasa aturan berbeda, tetapi makna longgarnya sama:

• Cloud Firestore — allow read, write: if true; di level database atau koleksi berarti seluruh dokumen bisa dibaca dan diubah tanpa login.
• Cloud Storage — allow read, write: if true; membuat unggah, unduh, dan daftar objek terbuka. Ini termasuk risiko penimpaan file dan penyalahgunaan kuota.
• Realtime Database — aturan berbentuk JSON dengan ".read": true, ".write": true. Sifatnya menurun ke bawah, jadi satu nilai true di root membuka seluruh pohon data.

Dalam ketiga kasus, yang bocor bukan hanya data. Yang bocor adalah kewenangan. Penyerang tidak perlu memahami aplikasi Anda; cukup memanggil endpoint yang sama seperti aplikasi Anda lakukan.

Kenapa aturan longgar mudah tertinggal

Ada beberapa jalur yang berulang:

• Mode uji bawaan saat membuat database memberi akses terbuka untuk masa tertentu. Masa itu habis, tetapi aturan tidak pernah diganti.
• Contoh dari tutorial disalin apa adanya karena fokusnya menyelesaikan fitur, bukan menyelesaikan izin.
• Aturan di emulator dan aturan di produksi dikelola terpisah, sehingga perbaikan hanya mendarat di salah satunya.
• Tidak ada yang menguji jalur tanpa autentikasi, jadi tidak ada yang tahu bahwa jalur itu masih hidup.

Hasil akhirnya sama: aturan longgar adalah utang keamanan yang menumpuk diam-diam, dan bunganya dibayar saat insiden terjadi.

Cara menguji sendiri dalam waktu singkat

Uji hanya proyek milik Anda atau proyek yang Anda punya izin tertulis untuk diuji. Langkahnya:

1. Ambil konfigurasi klien (misalnya apiKey dan projectId) dari bundle aplikasi Anda sendiri. Nilai ini memang dirancang publik.
2. Kirim permintaan baca ke endpoint Firestore tanpa header autentikasi. Jika dokumen kembali, artinya akses publik terbuka.
3. Ulangi dengan sesi anonim bila Anonymous Auth aktif. Banyak aturan longgar hanya menguji request.auth != null, sehingga akun anonim pun lolos.
4. Pada Realtime Database, coba akses ke URL database dengan akhiran .json tanpa token.
5. Pada Storage, coba unduh objek dan coba daftar objek di sebuah prefix.
6. Catat setiap respons: status, isi, dan apakah operasi tulis berhasil.

Pola aturan berbasis pemilik dokumen

Untuk sebagian besar aplikasi, aturan yang cukup adalah menolak secara default lalu membuka sesuai kebutuhan. Contoh untuk Firestore dengan dokumen yang menyimpan ownerId:

match /orders/{docId} { allow read: if request.auth != null && resource.data.ownerId == request.auth.uid; allow create: if request.auth != null && request.resource.data.ownerId == request.auth.uid; allow update, delete: if false; }

Beberapa hal yang perlu diperhatikan:

• Periksa request.resource.data pada operasi tulis, bukan hanya resource.data. Tanpa itu, pengguna bisa mengubah ownerId menjadi milik orang lain.
• Validasi field yang boleh diubah, misalnya status pembayaran atau peran, agar tidak bisa dinaikkan sendiri oleh klien.
• Untuk peran administratif, gunakan custom claims, bukan koleksi users yang bisa dibaca klien.
• Untuk Storage, kaitkan path dengan UID, misalnya users/{uid}/... dan bandingkan dengan request.auth.uid.
• Untuk Realtime Database, tulis aturan di level terdalam yang memungkinkan, jangan di root.

Aturan yang baik juga harus tetap bisa dibaca manusia enam bulan kemudian. Beri komentar singkat pada setiap blok.

Cara memeriksa apakah proyek Anda sudah terbuka

Sebelum menguji, lakukan audit cepat dari dalam konsol:

• Buka tab Rules untuk Firestore, Storage, dan Realtime Database. Cari if true, true, atau request.auth != null tanpa syarat tambahan.
• Periksa riwayat deploy aturan. Jika perubahan terakhir bertahun-tahun lalu, kemungkinan besar tidak ada yang menyentuhnya sejak mode uji.
• Pastikan aturan yang di-deploy adalah aturan yang Anda baca, bukan file lokal di repo yang berbeda.
• Gunakan Rules Playground untuk simulasi cepat, lalu konfirmasi dengan permintaan nyata dari klien.

AISG dapat membantu memberi indikasi awal. Sensor AISG berjalan lokal di mesin pengguna dan hasilnya adalah temuan yang perlu divalidasi manusia, bukan bukti eksploitasi. Untuk mencoba pemeriksaan awal, tersedia free URL scan tanpa akun di /#free-scan.

Batas pengujian manual dan emulator

Emulator Firebase sangat berguna, tetapi ia menjalankan aturan yang Anda muat ke dalamnya. Jika emulator memakai file aturan yang longgar, pengujian akan lolos dan produksi tetap terbuka. Pastikan file aturan yang diuji sama dengan yang di-deploy.

Rules Playground juga terbatas. Ia mengevaluasi satu permintaan dengan konteks yang Anda isi sendiri, tanpa data nyata dan tanpa melihat seluruh koleksi. Padahal kebocoran sering muncul dari subkoleksi yang terlupakan, koleksi lama yang tidak dipakai UI, atau aturan yang tumpang tindih.

Pengujian manual juga bergantung pada ingatan: siapa yang ingat menguji jalur anonim, jalur tulis, dan jalur daftar objek? Karena itu, jadikan pengujian aturan sebagai bagian dari alur rilis, bukan kegiatan sekali jalan. Setiap kali aturan berubah, ulangi skenario tanpa autentikasi, skenario pengguna biasa, dan skenario pengguna yang mencoba mengakses data orang lain.

Kesimpulan

Firebase tidak akan menolak aturan longgar. Ia hanya menjalankannya. Karena itu, firebase rules allow all harus diperlakukan sebagai temuan yang serius, bukan detail konfigurasi. Perbaikannya tidak mahal: mulai dari menolak default, buka per operasi, verifikasi kepemilikan di sisi server, dan uji jalur tanpa autentikasi setiap kali aturan berubah.

Alat otomatis, termasuk pemindaian AISG, hanya memberi indikasi. Keputusan akhir tetap ada di tangan Anda: baca aturan yang benar-benar berjalan di produksi, uji dengan klien nyata, dan pastikan setiap koleksi punya pemilik yang jelas.