// 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:
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.firestorebloğu Firestore'a kapsamlandırır. Realtime Database farklı bir JSON tabanlı sözdizimi kullanır; Cloud Storageservice firebase.storagekullanı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. Hemreadhem dewrite'a izin verilir;if truekoşulu da her zaman doğrudur.read,getvelistişlemlerini kapsar;write,create,updatevedelete'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; }
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; }
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.
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.
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.
