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

Firebase allow read, write: if true açıklaması: ne yaptığı ve nasıl düzeltileceği

Q: if true ve if request.auth != null arasındaki fark nedir?

if true anonim erişime izin verir — internetteki herkese. if request.auth != null oturum açmış herhangi bir kullanıcıyı gerektirir, ki bu daha iyidir ama hâlâ yanlıştır: uygulamanızın herhangi bir kullanıcısı diğer her kullanıcının verisini okuyabilir. Üretim kuralları request.auth.uid == resource.data.owner_uid veya benzeri yoluyla belirli kullanıcıya veya org'a kapsamlandırılmalıdır.

Q: Firebase if true kurallarını otomatik olarak sona erdirir mi?

Eski projelerde (2023 öncesi) if true kurallarını if false'a çeviren 30 günlük bir zamanlayıcı vardı. Mevcut projelerde yok — kural manuel olarak değiştirilene kadar belirsiz şekilde kalır. Projenizi 2023'ten önce oluşturduysanız ve kurallarınız iyi görünüyorsa, iki kez kontrol edin: zamanlayıcı onları if false'a çevirmiş olabilir, ki bu kendi uygulamanızı engeller.

Q: Uygulamam gerçekten public okumalı ise (blog, ürün kataloğu) ne olur?

Sonra yalnızca public koleksiyonda açıkça allow read: if true; allow write: if false; yazın — veritabanınızdaki her koleksiyonda değil. Koleksiyon başına ayrı bir match cümlesi kullanın ve özyinelemeli '{'document=**'}' joker karakterini asla yazılabilir kurallarda kullanmayın.

<code>allow read, write: if true;</code> üretimdeki en yaygın Firebase yanlış yapılandırmasıdır. Yeni bir veritabanı oluşturduğunuzda Firebase Console'un önerdiği test-modu varsayılanıdır, yapay zeka kodlama araçlarının dokümantasyondan yeniden ürettiği kuraldır ve tüm Firestore veritabanınızı internetteki herkese açan kuraldır. Bu makale sözdizimini kesin olarak açıklar, bu kural canlıyken bir saldırganın ne gördüğünü gösterir ve farklı kullanım senaryolarına uyan dört giderek daha sıkı alternatif verir.

Sözdizimi, satır satır

Tam bir Firestore test-modu kurallar belgesi altı satırdır:

firebase

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

Çözülmüş:

rules_version = '2'; v2 kural motorunu (güncel) seçer. Eski v1 kuralları kullanımdan kaldırılmıştır.
service cloud.firestore bloğu Firestore'a kapsamlandırır. Realtime Database farklı bir JSON tabanlı sözdizimi kullanır; Cloud Storage service firebase.storage kullanır.
match /databases/{database}/documents özel (default) veritabanını bağlar (çoğu projenin sadece bir tane vardır).
match /{document=**} özyinelemeli bir joker karakterdir. ** herhangi bir derinlikteki herhangi bir yolla eşleşir. {document} ile birleştiğinde, her koleksiyondaki her belgeyi yakalar — tüm veritabanını yöneten tek bir match cümlesi.
allow read, write: if true; kural gövdesidir. Hem read hem de write'a izin verilir; if true koşulu da her zaman doğrudur. read, get ve list işlemlerini kapsar; write, create, update ve delete'i kapsar.

Net etki: Firebase proje kimliğine ve doğru SDK'ya sahip herhangi bir istemci, herhangi bir koleksiyondaki herhangi bir belgeyi okuyabilir veya yazabilir. Kimlik doğrulama gerekmez. Hız sınırları uygulanmaz.

Firebase bunu neden varsayılan olarak gönderir

Firebase, bir proje oluşturduktan sonraki ilk 30 saniyede kod yazmanızı istiyor. Alternatif — herhangi bir okuma veya yazma çalışmadan önce size doğru bir kural yazmaya zorlamak — onboarding'i engellerdi. Bu yüzden Console bir veritabanı oluşturduğunuzda iki seçenek sunar: Production mode (her şeyi reddet, kuralları siz yazın) veya Test mode (30 gün boyunca her şeye izin ver). Çoğu geliştirici test modunu tıklar, sonra geri dönmeyi unutur. Eski projelerde 30 günlük zamanlayıcı vardı; mevcut projelerde otomatik son kullanma tarihi olmayan belirsiz bir if true kuralı vardır.

Yapısal sorun: yapay zeka kodlama araçları test-modu kuralları gösteren dokümantasyon, eğitimler ve Stack Overflow yanıtları üzerinde eğitilir. Cursor veya Claude Code'a "Firebase'i nasıl kurarım" diye sorduğunuzda, yanıt genellikle allow read, write: if true bloğunu sanki üretim kuralıymış gibi tam olarak içerir. Yapay zeka bilmiyor — ve bu kuralın üretim için güvenli olmadığını bilmeye yönlendirilmemiş.

Bir saldırgan ne görür

Somut olarak, Firebase proje kimliğinizi bilen (herhangi bir dağıtılmış uygulamanın paketinden 30 saniyede çıkarılabilir) ve aşağıdakini çalıştıran bir saldırgan her koleksiyondaki her belgeyi listeleyebilir:

Tek bir kimlik doğrulanmamış curl isteği her koleksiyonu sıralamak için yeterlidir. Aşağıdaki vurgulanmış bloğa bakın.

bash

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

Yanıt üst düzey koleksiyonların tam listesidir. Her koleksiyon için ikinci bir istek belgeleri döndürür. Bu yolda hız sınırı yoktur çünkü if true kuralları anonim trafiği kabul eder. Bir saatten kısa sürede milyonlarca belgenin sıralandığı Firebase veritabanları gördük.

Yazma yolunda: {fields} ile tek bir POST yeni bir belge oluşturur. Saldırganlar koleksiyonlarınızı çöple kirletebilir, Firestore'dan okuyan kullanıcıya dönük sayfaları tahrip edebilir veya veritabanınızı ücretsiz bir mesaj aracısı olarak kullanabilir — kullanım faturanız zıplar, araştırırsınız, fatura sorunu açıklar.

Dört üretim güvenli alternatif

Uygulamanızın veri modeline uyan alternatifi seçin. Dördü de kullanıcı kimlik doğrulamasına sahip olduğunuzu varsayar (Firebase Auth veya Firebase ID token'ı veren herhangi bir sağlayıcı):

Seçenek 1: Kullanıcı sahipliğindeki belgeler

En yaygın SaaS deseni. Belgeler /users/{userId}/... altında yaşar ve yalnızca sahibi onlara dokunabilir. 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çenek 2: Her belgede sahip alanı

Belgeler düz koleksiyonlarda yaşadığında (kullanıcı kimliği altında iç içe değil), bir owner_uid alanı saklayın ve onu kontrol edin. 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çenek 3: Çok kiracılı org izolasyonu

Org kapsamlı verili B2B SaaS için. Her belgede bir org_id alanı saklayın ve kullanıcının özel claim'ine karşı kontrol edin. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Kayıt sırasında Firebase Admin SDK aracılığıyla özel claim'in ayarlanmasını gerektirir.

firebase

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

Seçenek 4: Yalnızca okunur public içerik

Pazarlama içeriği, public profiller, ürün katalogları — gerçekten public okuma ama yalnızca admin yazma olan her şey için. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin özel claim'i yalnızca admin hesaplarda ayarlanır.

firebase

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

Hızlı denetim sorgusu

Düzeltmeden önce, if true'nun aslında canlı olup olmadığını kontrol edin. Firebase Console → Firestore → Rules'u açın ve if true'yu arayın. Yorum dışında herhangi bir yerde bulursanız, bir açık-kural bulgusu var demektir. Aynı UI'daki Rules simülatörü, saldırganın isteğini yerel olarak yeniden oynatmanızı sağlar — anonim bir GET /users/somebody yapıştırın ve simülatörün İzin Verildi döndürdüğünü teyit edin.

Harici teyit: üretim URL'nize karşı bir FixVibe taraması çalıştırın. baas.firebase-rules kontrolü Firestore, Realtime Database ve Storage kurallarınızı sondalar ve bir saldırganın keşfedeceği aynı bulguyu — Firebase Console'un gösterdiğinden bağımsız olarak — raporlar.

Sık sorulan sorular

<code>if true</code> ve <code>if request.auth != null</code> arasındaki fark nedir?

if true anonim erişime izin verir — internetteki herkese. if request.auth != null oturum açmış herhangi bir kullanıcıyı gerektirir, ki bu daha iyidir ama hâlâ yanlıştır: uygulamanızın herhangi bir kullanıcısı diğer her kullanıcının verisini okuyabilir. Üretim kuralları request.auth.uid == resource.data.owner_uid veya benzeri yoluyla belirli kullanıcıya veya org'a kapsamlandırılmalıdır.

Firebase <code>if true</code> kurallarını otomatik olarak sona erdirir mi?

Eski projelerde (2023 öncesi) if true kurallarını if false'a çeviren 30 günlük bir zamanlayıcı vardı. Mevcut projelerde yok — kural manuel olarak değiştirilene kadar belirsiz şekilde kalır. Projenizi 2023'ten önce oluşturduysanız ve kurallarınız iyi görünüyorsa, iki kez kontrol edin: zamanlayıcı onları if false'a çevirmiş olabilir, ki bu kendi uygulamanızı engeller.

Bir güvenlik ağı olarak gelecek tarihli bir zaman damgası kontrolü kullanabilir miyim?

Hayır — bir zaman damgası koşulu güvenlik kontrolü değildir. Açık kuralı gelecek bir tarihte sona erdirir, ki bu o tarihe kadar saldırganların tam erişim sahibi olduğu anlamına gelir. Ve tarihi unutursunuz. if true'yu zamana bağlı bir kuralla değil, auth kapsamlı bir kuralla değiştirin.

Uygulamam gerçekten public okumalı ise (blog, ürün kataloğu) ne olur?

Sonra yalnızca public koleksiyonda açıkça allow read: if true; allow write: if false; yazın — veritabanınızdaki her koleksiyonda değil. Koleksiyon başına ayrı bir match cümlesi kullanın ve özyinelemeli {document=**} joker karakterini asla yazılabilir kurallarda kullanmayın.

Sonraki adımlar

Üretim URL'nize karşı bir FixVibe taraması çalıştırın — baas.firebase-rules kontrolü if true'nun şu anda public internetten sömürülebilir olup olmadığını teyit eder. Tarayıcı mekanikleri ve Realtime Database ve Storage için paralel tespitler için Firebase kuralları tarayıcısı bölümüne bakın. Supabase'deki eşdeğer yanlış yapılandırma sınıfı için Supabase RLS tarayıcısı bölümünü okuyun.