FixVibe

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

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

allow read, write: if true; ü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

Concretely, an attacker who knows your Firebase project ID (it ships in every deployed app's configuration) can list every collection and read every document with plain, unauthenticated requests to Firebase's public REST API.

Once the collections are listed, every document in them can be read. Nothing slows this down, because if true rules accept anonymous traffic.

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.

External confirmation: run a FixVibe scan against your production URL. FixVibe checks your Firestore, Realtime Database, and Storage rules from the outside and reports what an attacker would find — independent of what the Firebase Console shows.

Sık sorulan sorular

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.

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.

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

Run a FixVibe scan against your production URL — it confirms whether if true is currently exploitable from the public internet. For how the scanner covers Realtime Database and Storage as well, see Firebase rules scanner. For the equivalent class of misconfiguration on Supabase, read Supabase RLS scanner.

// baas yüzeyinizi tarayın

Açık tabloyu başkası bulmadan önce bulun.

Bir üretim URL'si girin. FixVibe uygulamanızın konuştuğu BaaS sağlayıcılarını sıralar, açık endpoint'lerini parmak izlerine göre tespit eder ve kimliği doğrulanmamış bir istemcinin neleri okuyup yazabildiğini raporlar. Ücretsiz, kurulum yok, kart gerekmez.

  • Ücretsiz tarife — ayda 3 tarama, kayıt için kart gerekmez.
  • Pasif BaaS parmak izi — domain doğrulaması gerekmez.
  • Supabase, Firebase, Clerk, Auth0, Appwrite ve daha fazlası.
  • Coding-agent prompts where code/config applies, plus provider-console steps for hosted BaaS fixes.
Firebase allow read, write: if true açıklaması: ne yaptığı ve nasıl düzeltileceği · FixVibe