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

Firebase allow read, write: if true izahı: nə edir və necə düzəltmək olar

Q: if true ilə if request.auth != null arasındakı fərq nədir?

if true anonim girişə icazə verir — internetdəki hər kəs. if request.auth != null istənilən giriş etmiş istifadəçini tələb edir, bu daha yaxşıdır, lakin yenə də səhvdir: tətbiqinizin istənilən istifadəçisi hər digər istifadəçinin məlumatlarını oxuya bilər. Produksiya qaydaları request.auth.uid == resource.data.owner_uid və ya bənzəri vasitəsilə xüsusi istifadəçiyə və ya org-a əhatəli olmalıdır.

Q: Firebase if true qaydalarını avtomatik olaraq bitirirmi?

Köhnə layihələrdə (2023-dən əvvəl) if true qaydalarını if false-a çevirən 30 günlük taymer vardı. Cari layihələr bunu etmir — qayda manual olaraq dəyişdirilənə qədər müddətsiz qalır. Layihənizi 2023-dən əvvəl yaratdınız və qaydalarınız yaxşı görünür — iki dəfə yoxlayın: taymer onları artıq if false-a çevirmiş ola bilər, bu da öz tətbiqinizi bloklayır.

Q: Tətbiqim həqiqətən ictimai-oxuma (bloq, məhsul kataloqu) olarsa nə olar?

Onda yalnız ictimai kolleksiyada açıq allow read: if true; allow write: if false; yazın — verilənlər bazanızdakı hər kolleksiyada yox. Hər kolleksiya üçün ayrı bir match maddəsi istifadə edin və yazıla bilən qaydalarda heç vaxt rekursiv '{'document=**'}' joker simvolundan istifadə etməyin.

<code>allow read, write: if true;</code> produksiyada ən çox rast gəlinən Firebase səhv konfiqurasiyasıdır. Bu, Firebase Console-un yeni bir verilənlər bazası yaratdığınızda təklif etdiyi test-rejim standartıdır, AI kodlaşdırma alətlərinin sənədlərdən yenidən yaratdığı qaydadır və bütün Firestore verilənlər bazanızı internetdəki hər kəsə açan qaydadır. Bu məqalə sintaksisi dəqiq izah edir, bu qayda canlı olduqda hücumçunun nə gördüyünü göstərir və müxtəlif istifadə hallarına uyğun dörd ardıcıl olaraq daha sərt əvəz təklif edir.

Sintaksis, sətir-sətir

Tam bir Firestore test-rejim qaydaları sənədi altı sətirdir:

firebase

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

Deşifrə olunmuş:

rules_version = '2'; v2 qaydalar mühərrikini seçir (cari). Köhnə v1 qaydaları köhnəlib.
service cloud.firestore bloku Firestore-a əhatə edir. Realtime Database fərqli JSON əsaslı sintaksis istifadə edir; Cloud Storage service firebase.storage istifadə edir.
match /databases/{database}/documents xüsusi (default) verilənlər bazasına bağlanır (əksər layihələrdə yalnız bir tane olur).
match /{document=**} rekursiv joker simvoldur. ** hər dərinlikdəki istənilən yolu uyğunlaşdırır. {document} ilə birləşdirildikdə bu, hər kolleksiyadakı hər sənədi tutur — tək bir match maddəsi bütün verilənlər bazasını idarə edir.
allow read, write: if true; qayda gövdəsidir. Həm read, həm də write-a icazə verilir; if true şərti, yaxşı, həmişə doğrudur. read get və list əməliyyatlarını əhatə edir; write create, update və delete-i əhatə edir.

Net effekt: Firebase layihə ID-si və düzgün SDK olan istənilən müştəri istənilən kolleksiyadakı istənilən sənədi oxuya və ya yaza bilər. Identifikasiya tələb olunmur. Sürət məhdudiyyətləri tətbiq edilmir.

Firebase niyə bunu standart olaraq yayımlayır

Firebase, layihə yaratdıqdan sonra ilk 30 saniyədə kodlaşdırmanızı istəyir. Alternativ — hər oxumanın və ya yazmanın işləməsindən əvvəl düzgün bir qayda yazmağa məcbur etmək — onboarding-i bloklayardı. Beləliklə, Console verilənlər bazası yaratdığınızda iki seçim təklif edir: Production mode (hər şeyi rədd edin, qaydaları siz yazırsınız) və ya Test mode (30 gün ərzində hər şeyə icazə verin). Əksər tərtibatçılar test rejimini klikləyir və sonra onu yenidən ziyarət etməyi unudur. Köhnə layihələrdə 30 günlük taymer vardı; cari layihələrdə avtomatik bitmə müddəti olmayan müddətsiz if true qaydası var.

Struktur problemi: AI kodlaşdırma alətləri test-rejim qaydalarını göstərən sənədlər, dərsliklər və Stack Overflow cavabları üzərində təlim keçir. Cursor və ya Claude Code-dan "Firebase-i necə quraşdırmaq olar" deyə soruşduğunuzda, cavab tez-tez sanki produksiya qaydası imiş kimi məhz allow read, write: if true blokunu ehtiva edir. AI bunu bilmir — və bunu bilməyə təşviq edilmir — ki bu qayda produksiya üçün təhlükəsiz deyil.

Hücumçunun gördüyü

Konkret olaraq, Firebase layihə ID-nizi bilən (istənilən deploy olunmuş tətbiqin bundle-dən 30 saniyəyə çıxarıla bilər) hücumçu aşağıdakını işlədərək hər kolleksiyadakı hər sənədi sadalaya bilər:

Tək bir identifikasiyasız curl sorğusu hər kolleksiyanı sıralamaq üçün kifayətdir. Aşağıdakı vurğulanmış bloka baxın.

bash

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

Cavab üst-səviyyə kolleksiyaların tam siyahısıdır. Hər kolleksiya üçün ikinci bir sorğu sənədləri qaytarır. Bu yolda sürət limiti yoxdur, çünki if true qaydaları anonim trafiki qəbul edir. Milyonlarla sənədi olan Firebase verilənlər bazalarının bir saatdan az müddətdə sıralandığını gördük.

Yazma yolunda: {fields} ilə tək bir POST yeni bir sənəd yaradır. Hücumçular kolleksiyalarınızı zibillə doldura, Firestore-dan oxuyan istifadəçi-yönlü səhifələri pozaraq və ya verilənlər bazanızı pulsuz bir mesaj brokeri kimi istifadə edə bilərlər — istifadə hesabınız artır, araşdırırsınız, hesab problemi izah edir.

Dörd produksiyaya təhlükəsiz əvəz

Tətbiqinizin məlumat modelinə uyğun əvəz seçin. Hər dördü də sizin istifadəçi identifikasiyanız (Firebase Auth və ya Firebase ID token verən hər hansı provayder) olduğunu fərz edir:

Seçim 1: İstifadəçiyə məxsus sənədlər

Ən çox rast gəlinən SaaS nümunəsi. Sənədlər /users/{userId}/... altında yaşayır və yalnız sahibi onlara toxuna bilər. 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;
}

Seçim 2: Hər sənəddə sahib sahəsi

Sənədlər düz kolleksiyalarda yaşadıqda (istifadəçi ID altında yuvalanmamış), owner_uid sahəsi saxlayın və onu yoxlayın. 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;
}

Seçim 3: Çox-kirayəçi org təcridi

Org-əhatəli məlumatı olan B2B SaaS üçün. Hər sənəddə org_id sahəsi saxlayın və istifadəçinin xüsusi iddiası ilə yoxlayın. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Qeydiyyat zamanı Firebase Admin SDK vasitəsilə xüsusi iddianı təyin etməyi tələb edir.

firebase

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

Seçim 4: Yalnız-oxuma ictimai məzmun

Marketinq məzmunu, ictimai profillər, məhsul katalogları üçün — həqiqətən ictimai-oxuma, lakin yalnız admin-yazma olan hər şey. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin xüsusi iddiası yalnız admin hesablarda təyin olunur.

firebase

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

Sürətli audit sorğusu

Düzəlişdən əvvəl if true-nun əslində canlı olub-olmadığını yoxlayın. Firebase Console → Firestore → Rules açın və if true axtarın. Şərhdən kənar yerdə tapsanız, açıq-qayda tapıntınız var. Eyni interfeysdə olan Rules simulatoru sizə hücumçunun sorğusunu yerli olaraq oynatmağa imkan verir — anonim bir GET /users/somebody yapışdırın və simulatorun Allowed qaytardığını təsdiqləyin.

Xarici təsdiq: produksiya URL-inizə qarşı bir FixVibe skanı işlədin. baas.firebase-rules yoxlaması Firestore, Realtime Database və Storage qaydalarınızı zondlayır və hücumçunun kəşf edəcəyi eyni tapıntını bildirir — Firebase Console-un göstərdiyindən asılı olmayaraq.

Tez-tez verilən suallar

<code>if true</code> ilə <code>if request.auth != null</code> arasındakı fərq nədir?

if true anonim girişə icazə verir — internetdəki hər kəs. if request.auth != null istənilən giriş etmiş istifadəçini tələb edir, bu daha yaxşıdır, lakin yenə də səhvdir: tətbiqinizin istənilən istifadəçisi hər digər istifadəçinin məlumatlarını oxuya bilər. Produksiya qaydaları request.auth.uid == resource.data.owner_uid və ya bənzəri vasitəsilə xüsusi istifadəçiyə və ya org-a əhatəli olmalıdır.

Firebase <code>if true</code> qaydalarını avtomatik olaraq bitirirmi?

Köhnə layihələrdə (2023-dən əvvəl) if true qaydalarını if false-a çevirən 30 günlük taymer vardı. Cari layihələr bunu etmir — qayda manual olaraq dəyişdirilənə qədər müddətsiz qalır. Layihənizi 2023-dən əvvəl yaratdınız və qaydalarınız yaxşı görünür — iki dəfə yoxlayın: taymer onları artıq if false-a çevirmiş ola bilər, bu da öz tətbiqinizi bloklayır.

Gələcək-tarix zaman möhürü yoxlamasını təhlükəsizlik tədbiri kimi istifadə edə bilərəmmi?

Xeyr — zaman möhürü şərti təhlükəsizlik nəzarəti deyil. O, açıq qaydanı gələcək tarixdə bitirir, bu da o tarixə qədər hücumçuların tam girişi olması deməkdir. Və siz tarixi unudacaqsınız. if true-nu auth-əhatəli qayda ilə əvəz edin, zamanla məhdud olanla yox.

Tətbiqim həqiqətən ictimai-oxuma (bloq, məhsul kataloqu) olarsa nə olar?

Onda yalnız ictimai kolleksiyada açıq allow read: if true; allow write: if false; yazın — verilənlər bazanızdakı hər kolleksiyada yox. Hər kolleksiya üçün ayrı bir match maddəsi istifadə edin və yazıla bilən qaydalarda heç vaxt rekursiv {document=**} joker simvolundan istifadə etməyin.

Sonrakı addımlar

Produksiya URL-inizə qarşı bir FixVibe skanı işlədin — baas.firebase-rules yoxlaması if true-nun hazırda ictimai internetdən istismar oluna bildiyini təsdiqləyir. Skaner mexanikası və Realtime Database və Storage üçün paralel aşkarlamalar üçün Firebase qaydaları skaneri-nə baxın. Supabase-də eyni səhv konfiqurasiya sinifi üçün Supabase RLS skaneri oxuyun.