Semua panduan
Tingkat KritisKeamanan Database

Firebase Security Rules: jangan biarkan database-mu terbuka

Aplikasi web Firebase membaca dan menulis Firestore, Realtime Database, dan Cloud Storage langsung dari browser, memakai objek konfigurasi yang bisa dilihat siapa saja. Security Rules adalah satu-satunya hal yang menentukan apakah sebuah request diizinkan. Rules yang dibiarkan dalam test mode, atau dilonggarkan sampai mengizinkan segalanya, mengekspos seluruh database-mu ke internet.

Apa itu

Security Rules adalah bahasa policy kecil yang dievaluasi di server Google untuk setiap read dan write. Setiap blok match menargetkan sebuah path — collection, dokumen, folder storage — dan pernyataan allow menyebutkan operasi mana yang diizinkan dengan kondisi apa, memakai request.auth (siapa yang meminta) dan request.resource.data (apa yang ingin mereka tulis).

Konfigurasi web Firebase, termasuk apiKey-nya, hanya mengidentifikasi project-mu; itu bukan secret dan tidak memberi akses dengan sendirinya. Itulah kenapa rules sangat penting: pengunjung mana pun bisa menginisialisasi Firebase SDK dengan konfigurasimu dan meng-query database-mu langsung dari console browser mereka sendiri.

Kenapa penting

Test mode Firestore mengizinkan semua read dan write sampai tanggal kedaluwarsa. Saat tenggatnya tiba dan aplikasinya rusak, "perbaikan" yang umum adalah allow read, write: if true — yang membuat setiap dokumen bisa dibaca dan ditulis seluruh dunia. Database Firebase yang terekspos adalah sumber kebocoran data besar yang terus berulang, dan sangat mudah ditemukan lalu disedot.

Rules yang hanya memeriksa request.auth != null tidak jauh lebih baik: siapa pun bisa membuat akun, sering kali secara anonim, lalu membaca data semua user. Tanpa validasi write, user juga bisa mengubah field yang seharusnya tidak pernah mereka kendalikan — misalnya mengatur role: "admin" di profil mereka sendiri.

Cara memperbaiki

Ganti rules terbuka dengan rules berbasis pemilik

Tolak secara default dan berikan akses per collection. Di sini setiap user hanya bisa membaca dan menulis dokumennya sendiri di users, dan tidak ada hal lain yang bisa dijangkau.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
        && request.auth.uid == userId;
    }
    // Every other path is denied by default.
  }
}
Validasi apa yang boleh ditulis user

Batasi field mana yang boleh diubah user agar mereka tidak bisa menaikkan hak aksesnya sendiri atau mengutak-atik data yang dikelola server. affectedKeys().hasOnly() menolak update apa pun yang menyentuh field lain.

match /users/{userId} {
  allow update: if request.auth.uid == userId
    && request.resource.data.diff(resource.data)
         .affectedKeys().hasOnly(["displayName", "photoURL"]);
}
Hapus wildcard rekursif dan rules test mode

Cari di rules-mu match /{document=**} yang dikombinasikan dengan allow yang luas, if true, dan timestamp test mode yang bisa kedaluwarsa. Ingat bahwa Cloud Storage dan Realtime Database punya file rules terpisah — kunci juga keduanya.

Uji rules-mu seperti penyerang

Pakai Rules Playground di Firebase console atau Emulator Suite dengan @firebase/rules-unit-testing untuk menjalankan read sebagai user yang tidak terautentikasi dan sebagai user lain yang sudah login. Pengecekan eksternal yang cepat adalah request REST tanpa autentikasi — kalau mengembalikan dokumen, collection itu publik.

curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/users"

FAQ

Apakah apiKey Firebase-ku sebuah secret?

Bukan. apiKey di konfigurasi web Firebase mengidentifikasi project-mu dan memang dimaksudkan untuk dikirim ke browser. Lindungi datamu dengan Security Rules, dan batasi key-nya di Google Cloud hanya untuk API yang benar-benar dipakai aplikasimu agar tidak bisa dipakai ulang untuk layanan Google berbayar lainnya.

Apakah request.auth != null sudah cukup?

Jarang. Itu hanya membuktikan peminta sudah login — bukan bahwa datanya milik mereka. Bandingkan request.auth.uid dengan pemilik dokumen, atau periksa role yang tidak bisa diatur user sendiri.

Apakah AppSafe memeriksa rules Firebase-ku?

AppSafe tidak meng-query project Firebase-mu, jadi tidak bisa mengevaluasi rules-mu — pakai Rules Playground atau pengecekan curl di atas. Tapi AppSafe memang menandai Google API key (format AIza…) yang ditemukan di JavaScript-mu, karena format yang sama dipakai untuk layanan berbayar seperti Maps atau Gemini. Untuk konfigurasi web Firebase itu wajar; pastikan saja key-nya sudah dibatasi.

Apakah aplikasimu terpengaruh?

AppSafe memeriksa ini dan puluhan masalah lain dalam satu pemindaian gratis.

Pindai aplikasiku gratis