Firebase Entegrasyonları: Gerçek Zamanlı Veri ve Yetkilendirme

Firebase Entegrasyonları: Gerçek Zamanlı Veri ve Yetkilendirme konusu, yalnız birkaç SDK metodunu projeye eklemekten çok daha geniş bir backend tasarımını kapsar. Yaklaşık on yıllık web ve uygulama geliştirme deneyiminde gördüğüm en kritik hata, kullanıcı giriş yapabildiği anda sistemin güvenli kabul edilmesidir; oysa authentication kullanıcının kim olduğunu söylerken authorization hangi kaynağa hangi koşullarda erişebileceğini belirler. Firebase gerçek zamanlı veri ve authentication entegrasyonu nasıl yapılır, Firebase Realtime Database ile Firestore arasındaki farklar nelerdir, Firebase Authentication kullanıcı yetkilendirme ve rol yönetimi nasıl yapılır ve Firebase Security Rules ile gerçek zamanlı veri erişimi nasıl güvenli hale getirilir gibi soruların tamamı aynı mimari karar zincirinin parçalarıdır. Bu rehberde veri modelinden token yaşam döngüsüne, Security Rules tasarımından App Check'e, offline çalışma modelinden production maliyetlerine kadar uygulamada karşılaşacağınız konuları birlikte ele alacağız. Hedefimiz hızlı çalışan bir demo kurmaktan çok, gerçek kullanıcı trafiği altında ölçülebilen, yetkileri açık tanımlanmış ve ekiplerin uzun süre güvenle geliştirebileceği bir Firebase mimarisi oluşturmaktır.

Firebase Nedir?

Firebase, web ve mobil uygulamaların backend tarafında sık ihtiyaç duyduğu kimlik doğrulama, veri saklama, gerçek zamanlı senkronizasyon, dosya depolama, fonksiyon çalıştırma ve uygulama doğrulama gibi yetenekleri yönetilen servisler olarak sunan bir geliştirme platformudur. En önemli avantajlarından biri, istemci uygulamasının belirli Firebase servisleriyle doğrudan güvenli biçimde iletişim kurabilmesidir, ancak bu modelin güvenli olması Security Rules, Authentication ve gerektiğinde App Check katmanlarının doğru tasarlanmasına bağlıdır. Firebase yalnız hızlı prototip hazırlamak için kullanılan basit bir araç değildir; doğru domain sınırları, maliyet kontrolü ve güvenlik politikalarıyla uzun ömürlü ürünlerde de kullanılabilir. Bununla birlikte bütün iş kurallarını istemciye taşımak doğru değildir ve privileged işlemler için Cloud Functions, Cloud Run veya özel backend hâlâ gerekli olabilir. Firebase seçerken en önemli soru hangi servisin hangi sorumluluğu üstleneceğini baştan belirlemektir.

Backend as a Service (BaaS) Nedir?

Backend as a Service, uygulamaların yaygın backend ihtiyaçlarını sıfırdan sunucu kurup yönetmek yerine hazır ve yönetilen servisler üzerinden kullanmasını sağlayan yaklaşımdır. Authentication, database, storage ve serverless function gibi yetenekler servis sağlayıcı tarafından işletilirken ekip ürünün domain özelliklerine daha fazla zaman ayırabilir. Bu model operasyon yükünü azaltabilir, fakat veri modelinin, güvenlik kurallarının ve maliyet davranışının anlaşılmasını gereksiz hale getirmez. BaaS kullanan bir ekip yine authorization matrisi, environment ayrımı, gözlemlenebilirlik ve test stratejisi oluşturmalıdır. Ben BaaS yaklaşımını backend bilgisinin yerine geçen bir kestirme yol olarak değil, doğru sorumlulukları yönetilen altyapıya devreden mimari tercih olarak değerlendirmeyi daha sağlıklı buluyorum.

Firebase'in Temel Servisleri

Firebase tek bir database ürününden oluşmaz ve projenin ihtiyacına göre birlikte kullanılan birçok servis sunar. Authentication kullanıcı kimliğini yönetirken Cloud Firestore ve Realtime Database farklı veri modelleriyle gerçek zamanlı veri erişimi sağlar, Cloud Storage dosyaları saklar ve Cloud Functions güvenilir sunucu ortamında kod çalıştırabilir. App Check ise isteğin yetkili uygulama veya doğrulanmış cihaz bağlamından gelmesine yönelik ek bir koruma katmanı sunar. Bu servisleri birlikte kullanırken her birinin güvenlik sınırı açık biçimde belirlenmelidir. Örneğin App Check kullanmak Security Rules yazma ihtiyacını ortadan kaldırmaz ve kullanıcı giriş yapmış olması da document ownership kontrolünü otomatik olarak sağlamaz.

Firebase Authentication

Firebase Authentication kullanıcıların email ve password, sosyal identity provider, telefon veya custom authentication gibi yöntemlerle oturum açmasını yönetir. Başarılı oturum sonrasında istemci kullanıcıya ait UID ve token tabanlı kimlik bilgilerine ulaşabilir. Bu kimlik Security Rules veya backend token verification sırasında kullanılabilir. Authentication yalnız “bu kullanıcı kim?” sorusunu cevapladığı için resource access politikası ayrıca tasarlanmalıdır. Admin rolü, organization membership veya belirli bir document ownership gibi yetkiler Security Rules, custom claims ya da backend authorization üzerinden açıkça uygulanmalıdır.

Cloud Firestore

Cloud Firestore collection ve document temelli, sorgulanabilir ve gerçek zamanlı listener desteğine sahip JSON uyumlu document database yaklaşımı sunar. Veri nested collection ve subcollection yapılarıyla organize edilebilir, query ve index sistemi sayesinde belirli filtre ve sıralama ihtiyaçları modellenebilir. Firebase'in güncel resmi karşılaştırma rehberi yeni müşterilerin çoğu için başlangıç tercihi olarak Cloud Firestore'u öneriyor ve zengin veri modeli, sorgulanabilirlik, ölçeklenebilirlik ve offline erişimi öne çıkarıyor. Bununla birlikte query tasarımı Security Rules ile birlikte düşünülmeli, çünkü Firestore Rules sonuç kümesini sonradan filtreleyen bir mekanizma değildir. Veri modelini önce geliştirip authorization kuralını sonradan eklemek yerine ikisini birlikte tasarlamak çok daha güvenlidir. :contentReference[oaicite:1]{index=1}

Realtime Database

Realtime Database veriyi büyük bir JSON tree içinde tutan ve düşük gecikmeli senkronizasyonu temel alan klasik Firebase database servisidir. Basit lookup yapıları, presence sistemi, hızlı state paylaşımı ve bağlantı durumuna bağlı özellikler için güçlü bir seçenek olabilir. Query yetenekleri Firestore'a göre daha sınırlı olduğu için veri ağacının erişim ve sorgu yollarına göre dikkatli biçimde düzleştirilmesi gerekir. Security Rules path hiyerarşisiyle yakından ilişkilidir ve üst seviyede verilen read veya write izni alt seviyede geri alınamaz. Bu nedenle Realtime Database tasarımında data tree aynı zamanda güvenlik ve query mimarisinin önemli bir parçasıdır. :contentReference[oaicite:2]{index=2}

Cloud Storage

Cloud Storage görsel, video, doküman ve kullanıcı yüklemeleri gibi binary dosyaların saklanması için kullanılır. Dosyanın database document'ı içine base64 olarak yazılması yerine storage üzerinde tutulması bandwidth ve veri yönetimi açısından daha doğru olur. Erişim politikaları kullanıcı UID, dosya path'i veya metadata değerleri üzerinden Security Rules ile sınırlandırılabilir. Upload boyutu, MIME type ve kullanıcı ownership gibi doğrulamalar güvenlik stratejisinin parçası olmalıdır. Hassas dosyalarda istemci tarafındaki görünürlük kontrolüne güvenmeden sunucu tarafındaki kurallar üzerinden read ve write erişimi uygulanmalıdır.

Cloud Functions

Cloud Functions, istemcinin güvenilir şekilde yapmaması gereken işlemleri sunucu ortamında çalıştırmak için kullanılabilir. Admin claim atama, ödeme webhook'u işleme, aggregate hesaplama veya başka kullanıcıların verisini privileged biçimde değiştirme gibi işlemler buna örnektir. Function içinde Admin SDK kullanıldığında Firestore istemci Security Rules katmanının dışında çalışılabileceği için authorization kontrolü ayrıca backend kodunda yapılmalıdır. Function trigger'ları database event, authentication event veya HTTP request gibi olaylardan tetiklenebilir. Tasarımda “istemci yapabiliyor diye istemcide yapılmalı” yaklaşımı yerine güven sınırına göre iş dağılımı yapmak gerekir.

App Check

App Check, backend kaynaklarına gelen isteğin beklenen uygulama veya doğrulanmış cihaz bağlamından gelmesine yardımcı olan attestation tabanlı koruma katmanıdır. Firebase'in Ağustos 2026 güncel dokümantasyonuna göre web için reCAPTCHA Enterprise, Android için Play Integrity, Apple platformlarında App Attest veya DeviceCheck gibi sağlayıcılar destekleniyor ve Firebase Authentication desteği hâlen Preview durumunda listeleniyor. App Check kullanıcı kimliğinin yerine geçmez, Security Rules'un yerine de geçmez; amacı kötüye kullanım ve yetkisiz istemci kaynaklarını azaltmaktır. Enforcement etkinleştirilmeden önce metrics izlemek, gerçek kullanıcı trafiğinin ne kadarının valid token taşıdığını görmek açısından güvenli bir rollout yöntemidir. Local development ve CI ortamları için debug provider kullanılması gerekir. :contentReference[oaicite:3]{index=3}

Firebase Hangi Projelerde Kullanılır?

Firebase gerçek zamanlı chat, görev yönetimi, etkinlik uygulaması, mobil ürün, içerik sistemi, dashboard, bildirim tabanlı uygulama ve hızlı MVP gibi birçok kullanım alanında değerlendirilebilir. Özellikle kullanıcı state'inin birden fazla cihaz arasında hızlı senkronize edilmesi veya offline çalışma beklentisi bulunduğunda Firestore ve Realtime Database önemli avantaj sağlar. Bununla birlikte çok ağır relational reporting, yoğun cross-entity transaction veya veri taşınabilirliğinin birincil gereksinim olduğu projelerde özel backend ve farklı database seçenekleri daha uygun olabilir. Firebase en iyi sonucu servis sınırları domain ihtiyacına uyduğunda verir. Proje başında veri erişim yollarını, authorization modelini ve maliyet üreten read ile listener davranışlarını modellemek sonraki büyüme döneminde ciddi zaman kazandırır.

Firebase ile Geleneksel Backend Arasındaki Fark

Geleneksel backend mimarisinde istemci çoğunlukla özel API sunucusuna istek gönderir, sunucu kullanıcıyı doğrular, database'e erişir ve sonucu geri döndürür. Firebase client SDK modelinde ise istemci belirli servislerle doğrudan iletişim kurabilir ve Security Rules server tarafında erişim kararını uygular. Bu yapı API boilerplate miktarını azaltabilir, ancak authorization yükünü ortadan kaldırmaz; aksine Security Rules ve veri modelinin birlikte tasarlanmasını daha önemli hale getirir. Privileged business logic, ödeme, role assignment veya gizli credential gerektiren işlemler yine güvenilir backend ortamında çalıştırılmalıdır. En sağlıklı yaklaşım çoğu zaman client-direct veri erişimi ile server-side privileged işlemleri aynı mimari içinde doğru sınırlar üzerinden birleştirmektir.

Client'ın Database'e Doğrudan Erişmesi

Firebase SDK kullanan web veya mobil client, Firestore ya da Realtime Database'e doğrudan bağlantı kurabilir ve izin verilen veriyi okuyup yazabilir. Bu modelde arada her operasyon için sizin yazdığınız REST endpoint bulunması zorunlu değildir. Güvenlik sorumluluğu client koduna bırakılmaz, çünkü gerçek authorization Firebase sunucularında Security Rules üzerinden uygulanmalıdır. Client tarafında bir butonu gizlemek yalnız UX kararıdır ve kötü niyetli kullanıcı network isteğini doğrudan gönderebilir. Bu nedenle database path, query shape ve Security Rules aynı access contract'ın parçaları gibi tasarlanmalıdır.

Serverless Veri Erişimi

Serverless veri erişimi ekibin her CRUD işlemi için kendi application server'ını çalıştırmak zorunda kalmaması anlamına gelir. Firestore veya Realtime Database SDK doğrudan backend servisiyle iletişim kurarken Authentication token ve Security Rules erişim kontrolüne katılır. Bu model chat, profile, notification state veya collaborative data gibi birçok feature'ın daha az backend koduyla geliştirilmesini sağlayabilir. Ancak business işlem birden fazla güvenilir kaynağı kontrol etmeli, secret kullanmalı veya yetki yükseltmeli ise serverless client access yeterli değildir. Bu tür operasyonlar Cloud Functions, Cloud Run veya başka backend servisinde yürütülmelidir.

Security Rules'un Merkezi Rolü

Security Rules istemci tarafından gelen database ve storage isteklerini server tarafında allow veya deny kararına dönüştüren temel policy katmanıdır. Kurallar authentication bilgisini, document içeriğini, incoming data'yı veya path parametrelerini inceleyebilir. Firebase'in resmi dokümantasyonu Security Rules'un uygulama kodundan bağımsız çalıştığını ve client bug'ının tek başına veri güvenliğini bozmaması için bu ayrımın önemli olduğunu vurguluyor. Rules dosyasını source control içinde tutmak, Emulator Suite ile test etmek ve CI pipeline'a dahil etmek bu nedenle production güvenliğinin doğal parçasıdır. Console üzerinde elle değişiklik yapıp test yazmamak sürdürülebilir bir ekip yaklaşımı değildir. :contentReference[oaicite:4]{index=4}

Hangi İşlemler İçin Backend Hâlâ Gereklidir?

Admin role atama, service account kullanımı, ödeme webhook'u, secret içeren üçüncü taraf API çağrısı, global aggregate hesaplama ve başka kullanıcının kaynağını privileged biçimde değiştirme gibi işlemler güvenilir backend ortamında yapılmalıdır. Client içinde Admin SDK veya service account private key bulunmamalıdır. Backend gelen Firebase ID token'ı doğrulayıp UID ve custom claim bilgilerini aldıktan sonra kendi authorization kararını uygulayabilir. Server SDK kullanıldığında Firestore Security Rules bypass edildiği için “zaten Rules var” düşüncesi backend'i güvenli hale getirmez. Sunucu tarafı IAM ve application-level authorization ayrıca uygulanmalıdır. :contentReference[oaicite:5]{index=5}

Firebase Authentication, Authorization ve App Check Arasındaki Fark

Firebase güvenliğini anlamanın en önemli adımlarından biri Authentication, Authorization ve App Check kavramlarını birbirinden ayırmaktır. Authentication kullanıcının kimliğini doğrular, authorization doğrulanmış kullanıcının hangi kaynağa ne yapabileceğini belirler ve App Check isteğin beklenen uygulama ya da cihaz bağlamından gelmesine yardımcı olur. Bu üç katman birbirinin yerine kullanılmaz. Kullanıcı geçerli App Check token taşısa bile başka kullanıcının document'ını okumaya yetkili olmayabilir. Aynı şekilde Firebase Authentication ile giriş yapmış bir client, doğru Security Rules olmadan bütün database'e erişmemelidir.

Authentication — Kullanıcı Kim?

Authentication kullanıcının kim olduğunu doğrulamaya odaklanır ve başarılı sign-in sonrasında Firebase bir user identity oluşturur. UID kullanıcıyı project içinde benzersiz biçimde tanımlamak için kullanılabilir. Client ID token alabilir ve backend bu token'ı doğrulayarak kullanıcının kimliğini öğrenebilir. Authentication kullanıcının admin, editor veya resource owner olup olmadığını kendiliğinden belirlemez. Bu nedenle sign-in tamamlanması güvenlik sürecinin sonu değil authorization değerlendirmesinin başlangıcıdır.

Authorization — Kullanıcı Ne Yapabilir?

Authorization kullanıcının belirli resource üzerinde read, create, update veya delete işlemlerinden hangisini yapabileceğini belirler. Basit sistemde kullanıcının yalnız kendi UID path'ine erişmesi yeterli olabilirken kurumsal projelerde organization membership, role, project membership ve document attribute birlikte değerlendirilebilir. Firestore Security Rules veya Realtime Database Rules client request'leri için bu policy'yi uygular. Backend endpoint kullanılıyorsa aynı authorization logic sunucu tarafında ayrıca çalıştırılmalıdır. Kullanıcı UI'da admin badge gördüğü için güvenilir admin kabul edilmemeli, trusted token claim veya server-side membership kontrolü yapılmalıdır.

App Check — Request Hangi Uygulamadan Geliyor?

App Check kullanıcının kimliğini değil request'in beklenen uygulama veya attestation bağlamından gelip gelmediğini değerlendirir. Bir saldırgan Firebase config değerlerini kopyalayıp doğrudan backend kaynaklarına istek göndermeye çalıştığında App Check abuse riskini azaltmaya yardımcı olabilir. Güncel Firebase dokümantasyonunda web tarafında reCAPTCHA Enterprise, Android tarafında Play Integrity ve Apple platformlarında App Attest ile DeviceCheck seçenekleri öne çıkıyor. Ancak valid App Check token bir kullanıcının belirli document'ı okumaya yetkili olduğu anlamına gelmez. Authorization kararı yine Security Rules veya backend policy tarafından verilmelidir. :contentReference[oaicite:6]{index=6}

Üç Güvenlik Katmanı Birlikte Nasıl Çalışır?

Tipik akışta kullanıcı Firebase Authentication üzerinden giriş yapar, client gerekli servis request'lerinde geçerli auth token ve desteklenen servislerde App Check token taşır, Security Rules ise UID, claim veya resource verisine göre access kararını verir. App Check kötüye kullanılan sahte client kaynaklarını azaltırken Authentication user identity sağlar. Authorization en kritik data boundary'yi uygular ve hangi user'ın hangi path veya document üzerinde işlem yapacağını belirler. Backend kullanılıyorsa ID token doğrulandıktan sonra aynı access policy sunucu kodunda uygulanmalıdır. Bu katmanları üst üste koymak tek bir koruma yöntemine aşırı güvenmekten daha sağlam bir güvenlik modeli oluşturur.

Firebase Realtime Database Nedir?

Firebase Realtime Database verileri JSON tree olarak saklayan ve bağlı client'lara değişiklikleri düşük gecikmeyle ileten gerçek zamanlı database servisidir. Client belirli path'lere listener bağlayabilir ve server üzerindeki değişiklikler bağlantı üzerinden yeni event'ler olarak iletilir. Presence, online status veya hızlı state senkronizasyonu gibi özelliklerde bağlantı modelinin sağladığı avantajlar belirgindir. Buna karşılık geniş JSON tree'yi sürekli dinlemek bandwidth ve güvenlik sorunlarına yol açabileceği için path'ler dar ve sorgular sınırlı tasarlanmalıdır. Veri modelinin query, rules ve ownership ihtiyaçlarıyla birlikte planlanması Realtime Database başarısında belirleyicidir.

JSON Tree Veri Modeli

Realtime Database veriyi collection ve document yerine tek büyük JSON tree mantığıyla organize eder. Bu model ilk bakışta basit görünse de iç içe veri çok derinleşirse okuma ve güvenlik sınırları zorlaşabilir. Örneğin bir parent path okunduğunda altındaki büyük subtree de transfer edilebilir. Bu nedenle normalize relational yapı yerine kullanım senaryosuna göre belirli alanlarda denormalization sık uygulanır. User membership, room metadata ve message stream gibi verileri farklı path'lere ayırmak query ve authorization üzerinde daha iyi kontrol sağlar.

Realtime Synchronization

Realtime synchronization, listener'ın bağlı olduğu path veya query sonucunda değişiklik oluştuğunda client'ın yeni state'i otomatik almasını sağlar. Client sürekli polling endpoint çağırmak zorunda kalmaz. Bu davranış chat, collaborative presence veya live counter gibi ekranlarda development modelini sadeleştirebilir. Buna rağmen her değişikliğin kullanıcıya gerekli olup olmadığı sorgulanmalıdır, çünkü gereksiz listener bandwidth ve render yükü yaratır. Listener scope'u mümkün olduğunca küçük tutulmalı ve component kullanılmadığında abonelik sonlandırılmalıdır.

Long-Lived Client Connection

Realtime Database client'ı server ile uzun süreli bağlantı koruyarak veri event'lerini düşük gecikmeyle alabilir. Bu bağlantı yapısı online durum bilgisi ve disconnect callback gibi özelliklere zemin hazırlar. Kullanıcı network değiştirdiğinde reconnect olabilir ve uygulama mevcut state'i yeniden senkronize eder. Uzun bağlantı “sınırsız listener eklenebilir” anlamına gelmez, çünkü her aktif listener veri ve işlem maliyeti oluşturabilir. Production monitoring içinde concurrent connection, bandwidth ve listener davranışları takip edilmelidir.

Offline Davranış

Realtime Database SDK'ları bağlantı kesildiğinde local state ve queued write davranışlarıyla kullanıcı deneyimini sürdürebilir. Mobil istemcilerde disk persistence seçenekleri daha güçlü olabilirken web davranışı platforma göre farklı ele alınmalıdır. Offline write kullanıcıya hemen local event gösterebilir ve bağlantı geldiğinde server ile senkronize edilir. Conflict veya stale data ihtimali UX içinde açık biçimde düşünülmelidir. Uygulama “offline çalışıyor” dediğinde yalnız veri yazabilmeyi değil kullanıcının hangi bilginin server tarafından onaylandığını anlayabilmesini de sağlamalıdır.

Presence Desteği

Presence Realtime Database'in en güçlü kullanım alanlarından biridir çünkü /.info/connected bağlantı durumunu izlemeye ve onDisconnect() server tarafında disconnect olduğunda önceden planlanmış işlemi yürütmeye yardımcı olur. Firebase'in güncel örnekleri multi-device presence için her bağlantıyı ayrı child olarak saklamayı ve last online timestamp değerini disconnect sırasında server timestamp ile güncellemeyi öneriyor. Önemli ayrıntı, race condition riskini azaltmak için onDisconnect işlemlerini kullanıcıyı online işaretlemeden önce sıraya almaktır. Bu model browser kapanması veya network kaybı gibi durumlarda “ghost online” kayıtlarını azaltır. Presence verisinin ayrı path'te tutulması main application document'larından bağımsız ölçeklenmesine de yardımcı olur. :contentReference[oaicite:7]{index=7}

Hangi Projelerde Realtime Database Kullanılmalı?

Presence, basit chat, live connection state, düşük gecikmeli küçük veri ağacı veya basit lookup ağırlıklı uygulamalarda Realtime Database iyi tercih olabilir. Firebase'in güncel database karşılaştırması da Realtime Database'i basit veri modeli ve düşük gecikmeli senkronizasyon ihtiyacına uygun klasik Firebase JSON database olarak tanımlıyor. Daha gelişmiş query kombinasyonları, collection document modeli ve geniş ölçekli document sorguları gerekiyorsa Firestore çoğu projede daha rahat olabilir. İki database aynı project içinde farklı görevler için birlikte de kullanılabilir; örneğin Firestore business data'yı, Realtime Database presence bilgisini taşıyabilir. Seçimi popülerlik üzerinden değil query, presence, scaling ve maliyet profilinden yapmak gerekir. :contentReference[oaicite:8]{index=8}

Cloud Firestore Nedir?

Cloud Firestore collection ve document tabanlı NoSQL database yapısı sunar ve realtime listener, query, index ve offline persistence gibi yetenekleri bir arada sağlar. Document yapısı domain entity'lerini JSON uyumlu alanlarla temsil etmeyi kolaylaştırır. Query yeteneği Realtime Database'e göre daha zengindir, ancak query ile Security Rules'un aynı erişim koşullarını paylaşması gerekir. Firestore birçok index'i otomatik yönetir ve karma filtre-sıralama senaryolarında composite index isteyebilir. Production tasarımında document boyutu, write frequency, hot document riski, listener fan-out ve read maliyeti birlikte değerlendirilmelidir.

Collection

Collection aynı tür veya aynı domain altında gruplanan document'ların container'ıdır. Örneğin users, projects veya orders birer collection olabilir. Collection doğrudan field taşımaz, document içerir. Security Rules collection path pattern'i üzerinden document erişimini kontrol edebilir. Query tasarımını collection sınırıyla birlikte düşünmek ownership ve tenant isolation modelini daha anlaşılır hale getirir.

Document

Document key-value alanlar içeren temel Firestore veri birimidir ve benzersiz document ID üzerinden adreslenir. User profile, task veya organization gibi entity'ler document olarak modellenebilir. Sensitive field'ları aynı document içinde tutmak her kullanıcıya partial document read vermeyi engeller, çünkü Firestore read document seviyesinde gerçekleşir. Farklı gizlilik seviyesindeki bilgiler ayrı document veya subcollection içinde tutulmalıdır. Firebase'in güvenlik dokümantasyonu belirli alanları kullanıcıdan saklamak gerekiyorsa bunları ayrı document'a taşımanın doğru model olduğunu açıkça anlatır. :contentReference[oaicite:9]{index=9}

Subcollection

Subcollection bir document altında yeni collection hiyerarşisi kurmayı sağlar ve membership, comments veya private metadata gibi alt kaynakları modellemek için kullanılabilir. Parent document silindiğinde subcollection'ların otomatik olarak her durumda silinmediği gerçeği lifecycle tasarımında dikkate alınmalıdır. Rules path'i parent ile child ilişkisinden yararlanabilir, fakat subcollection access için explicit match gerekebilir. Çok derin hiyerarşi query ve cleanup operasyonlarını zorlaştırabilir. Domain yapısını anlaşılır tutmak, yalnız URL benzeri path estetiği uğruna derin nesting yapmaktan daha değerlidir.

Query

Firestore query, collection veya collection group içinden belirli field condition, order ve limit ile result set seçmeye yarar. Security Rules query sonucunu belge belge sonradan filtrelemez, request'in potansiyel sonuç kümesinin kurallara uyup uymadığını değerlendirir. Bu nedenle “collection'ın tamamını çekeyim, Rules yalnız bana ait document'ları döndürsün” yaklaşımı çalışmaz. Query ownership condition taşımalı ve rules aynı constraint'i kabul etmelidir. Bu tasarım veri modeli, index ve authorization kararlarının birlikte yapılmasını zorunlu kılar. :contentReference[oaicite:10]{index=10}

Index

Firestore sorgu performansını index tabanlı yürütür ve birçok single-field index otomatik oluşturulur. Birden fazla field filter veya filter ile sort kombinasyonunda composite index gerekebilir. Firebase console hata mesajı üzerinden eksik index oluşturma bağlantısı sağlayabilir. Her field için gereksiz index tutmak storage ve write maliyetini artırabileceği için kullanılmayan index yapılarını değerlendirmek gerekir. Index tasarımı query pattern'lerden sonra değil onlarla birlikte planlanmalıdır.

Realtime Listener

Realtime listener document, collection veya query sonucundaki değişiklikleri client'a snapshot olarak iletir. İlk snapshot mevcut sonuç setini içerir, daha sonraki event'ler incremental changes hakkında bilgi sağlayabilir. Listener'ın scope'u genişledikçe read ve render maliyeti artabilir. Kullanıcı yalnız kendi organization verisini görüyorsa listener query de aynı tenant constraint'i taşımalıdır. Component unmount olduğunda unsubscribe edilmemesi memory ve network davranışını gereksiz yere sürdürebilir.

Offline Persistence

Firestore offline persistence aktif olduğunda uygulama kullanılan verinin cache kopyasını tutabilir, cached data üzerinde read, query ve listener çalıştırabilir ve connection geri geldiğinde local write'ları backend ile senkronize edebilir. Güncel Firebase dokümantasyonuna göre Android ve Apple platformlarında persistence varsayılan olarak açıkken web tarafında persistent cache varsayılan değildir ve açık biçimde etkinleştirilmelidir. Web cache oturumlar arasında otomatik temizlenmediği için hassas veri işleyen uygulamalarda kullanıcıya trusted device olup olmadığını sormak önemlidir. Chrome, Safari ve Firefox web persistence desteği resmi dokümanda özellikle belirtiliyor. Aynı document'a birden fazla offline değişiklik geldiğinde Firestore senkronizasyon modelinde last write wins davranışı uygulanabilir. :contentReference[oaicite:11]{index=11}

Realtime Database ve Firestore Arasındaki Fark

Firebase Realtime Database ile Firestore arasındaki farklar nelerdir sorusunun tek cevabı “biri eski, biri yeni” değildir. İki servis veri modeli, query yeteneği, presence, offline davranış, scaling ve pricing yaklaşımı bakımından farklı trade-off sunar. Firebase güncel rehberinde yeni müşterilerin çoğuna Cloud Firestore ile başlamayı önerirken Realtime Database'i basit veri modeli ve düşük gecikmeli synchronization için hâlâ uygun seçenek olarak konumlandırıyor. Presence ihtiyacında Realtime Database'in /.info/connected ve onDisconnect() mekanizması önemli avantaj sağlayabilir. Bir projede ikisini farklı sorumluluklarla birlikte kullanmak da geçerli bir mimaridir. :contentReference[oaicite:12]{index=12}

Veri Modeli

Realtime Database tek JSON tree modeli kullanırken Firestore collection, document ve subcollection yapısı sunar. JSON tree ilişkisel olmayan basit state için hızlı anlaşılır, fakat veri büyüdükçe denormalization ve path tasarımı önem kazanır. Firestore document modeli domain entity'lerini ayrı resource olarak modellemeyi ve farklı query pattern'leri desteklemeyi kolaylaştırabilir. Authorization da veri modeliyle yakından ilişkilidir, çünkü Security Rules path veya document field'larını kullanır. Bu nedenle migration yalnız SDK değiştirmek değil data access pattern'i yeniden düşünmek anlamına gelebilir.

Query Yeteneği

Firestore field filter, order, limit ve composite index kombinasyonlarıyla daha zengin query modeli sunar. Realtime Database query yetenekleri daha sınırlıdır ve genellikle tek ordering dimension etrafında tasarım yapılır. Karmaşık dashboard filtreleri veya farklı collection sorguları gerekiyorsa Firestore geliştirici deneyimini iyileştirebilir. Buna karşılık simple key lookup veya ordered feed Realtime Database için yeterli olabilir. Query requirement'larını baştan yazmak database seçimini daha objektif hale getirir.

Realtime Synchronization

Her iki database de realtime listener sunabilir ve client değişiklikleri düşük gecikmeyle alabilir. Realtime Database ismindeki “Realtime” kelimesi Firestore'un gerçek zamanlı olmadığı anlamına gelmez. Firestore onSnapshot() ile document veya query result değişikliklerini stream benzeri biçimde iletebilir. Fark daha çok veri modeli, query semantics ve connection özelliklerinde ortaya çıkar. Presence veya çok basit state stream'i söz konusu olduğunda Realtime Database doğal hissedebilir.

Offline Support

Firestore offline persistence web, Android ve Apple platformlarında desteklenir, ancak web tarafında persistent cache açık biçimde etkinleştirilmelidir. Realtime Database de offline write ve local event davranışları sağlar ve mobil SDK'larda persistence özellikleri kullanılabilir. Offline-first uygulamada hangi verinin cache'de kaldığı, logout sonrası nasıl davranılacağı ve conflict durumunda kullanıcıya ne gösterileceği ayrıca tasarlanmalıdır. “SDK offline çalışıyor” ifadesi güvenlik ve UX stratejisini otomatik çözmez. Hassas bilgiler shared cihazda persistent browser cache içinde uzun süre kalmamalıdır.

Presence

Presence açısından Realtime Database daha doğrudan primitive'ler sunar. /.info/connected client connection state'ini izler ve onDisconnect() bağlantı koptuğunda server tarafında önceden tanımlanmış işlemi yürütebilir. Firestore native olarak aynı presence primitive'ini sunmadığı için birçok mimaride presence Realtime Database üzerinde, kalıcı domain data Firestore üzerinde tutulur. Multi-device presence her bağlantıyı ayrı child olarak saklayarak daha doğru modellenebilir. Last seen timestamp disconnect operation üzerinden güncellenebilir. :contentReference[oaicite:13]{index=13}

Security Rules

Her iki database Security Rules kullanır, ancak syntax ve path behavior aynı değildir. Realtime Database read ve write rules yukarıdan aşağı cascade eder ve parent path'te verilen izin child path'te geri alınamaz. Firestore rules explicit path match üzerinden daha granular document access tanımlar. Firestore query güvenliği potansiyel result set üzerinden değerlendirilirken Realtime Database Rules da query ve path modeline göre atomic access kararı verir. Database seçerken ekibin rules behavior'ını gerçekten anlaması güvenlik açısından en az query API bilgisi kadar önemlidir. :contentReference[oaicite:14]{index=14}

Scaling

Firestore zengin query modeli ve document tabanlı scaling yaklaşımıyla geniş uygulamalarda rahat seçenek olabilir. Realtime Database de yüksek trafik taşıyabilir, ancak veri ağacı, concurrent connections, bandwidth ve gerekirse database sharding tasarımı önem kazanır. Hot key veya yüksek write yoğunluğu her database türünde mimari inceleme gerektirir. Büyük uygulamada “Firebase otomatik ölçekleniyor” düşüncesi gözlemlenebilirlik ihtiyacını ortadan kaldırmaz. Query scope, listener fan-out ve write pattern production trafiğiyle izlenmelidir.

Pricing

Firestore maliyetinde document read, write, delete, storage ve network gibi unsurlar önem taşırken Realtime Database kullanımında stored data, downloaded data ve plan limitleri farklı biçimde etkili olabilir. Fiyatlandırma zamanla değişebildiği için mimari karar exact rakama bağlanmamalı ve güncel resmi pricing sayfasıyla doğrulanmalıdır. Uygulama tasarımında gereksiz geniş listener, tekrar read veya büyük JSON subtree transferi maliyeti büyütebilir. Maliyet analizi sadece aylık user sayısıyla değil user başına read, listener ve bandwidth davranışıyla yapılmalıdır. Budget alert ve usage dashboard erken aşamada kurulmalıdır.

Hangi Projede Hangisi Tercih Edilmeli?

Rich query, document model, collection tabanlı authorization ve genel-purpose application data gerekiyorsa Firestore güçlü başlangıç tercihidir. Presence, connection state veya çok basit düşük gecikmeli JSON synchronization gerekiyorsa Realtime Database öne çıkabilir. Karma mimaride kullanıcı profile ve content Firestore'da, online presence Realtime Database'de tutulabilir. Migration maliyetini azaltmak için repository katmanı veya data access abstraction kullanılabilir, ancak gereksiz abstraction da geliştirmeyi ağırlaştırmamalıdır. Seçim query matrix, authorization matrix, offline ihtiyacı ve beklenen maliyet modeline göre belgelenmelidir.

Firebase Projesi Nasıl Kurulur?

Firebase projesi kurulurken yalnız console içinde “Create project” düğmesine basıp config kopyalamak yeterli değildir. Development, staging ve production environment'larının birbirinden ayrılması; doğru app registration yapılması; Authentication provider, database location ve App Check stratejisinin planlanması gerekir. Web, Android, iOS ve Flutter uygulamaları aynı Firebase project altında ayrı app registration kullanabilir. Production verisi local development sırasında yanlışlıkla değiştirilmemelidir. Bu nedenle environment variable ve project alias düzeni proje başlamadan kurulursa deployment hataları önemli ölçüde azalır.

Firebase Project Oluşturma

Project oluştururken isim kadar billing account, Google Cloud project ilişkisi, region ve hangi Firebase ürünlerinin kullanılacağı düşünülmelidir. Development ve production için ayrı project oluşturmak data isolation sağlar. Ekibin console IAM rolleri least-privilege yaklaşımıyla verilmelidir. Her developer'a gereksiz owner yetkisi vermek yerine görev bazlı izin tercih edilmelidir. Project ID client config içinde görülebilir ve security secret olarak değerlendirilmez.

Web Uygulaması Ekleme

Web app registration sonrasında Firebase config object elde edilir ve modular JavaScript SDK ile initialization yapılabilir. Config içindeki Firebase API key, project ID ve app ID client uygulamasında bulunabilir, ancak bu bilgi database authorization sağlamaz. Environment'a göre doğru project config seçilmelidir. Production build'in yanlışlıkla development project'e bağlanması monitoring ve data ayrımını bozar. App Check ve authorized domain ayarları production rollout öncesi doğrulanmalıdır.

Android Uygulaması Ekleme

Android registration package name üzerinden yapılır ve gerekli config dosyası uygulamaya eklenir. Authentication provider veya App Check Play Integrity kullanılıyorsa signing certificate ve build variant bilgileri önem kazanabilir. Debug ve release build farklı environment project'lerine yönlendirilebilir. CI pipeline secret ve config yönetimi repository yapısına göre planlanmalıdır. Android offline behavior ve network reconnect senaryoları emulator yanında gerçek cihazda da test edilmelidir.

iOS Uygulaması Ekleme

iOS app registration bundle identifier üzerinden yapılır ve Firebase config dosyası application target'a eklenir. Apple authentication veya App Check App Attest kullanıldığında Apple developer configuration ile Firebase ayarlarının uyumlu olması gerekir. Debug ve release environment separation build configuration üzerinden yönetilebilir. Keychain ve user session behavior logout testlerinde kontrol edilmelidir. Push notification, authentication ve database initialization ayrı lifecycle gereksinimlerine göre kurulmalıdır.

FlutterFire Yapılandırması

FlutterFire CLI platformlara uygun Firebase configuration üretmeyi kolaylaştırabilir ve Android, iOS ile web app registration'larını tek Flutter project içinde yönetmeye yardımcı olur. Environment ayrımı flavor veya farklı Firebase option dosyaları üzerinden yapılabilir. Flutter stream yapısı Firestore ve Realtime Database listener'larıyla doğal biçimde entegre olur. Widget dispose sırasında stream subscription veya controller lifecycle dikkatle yönetilmelidir. Security Rules hiçbir zaman Flutter UI role kontrolüne bırakılmamalıdır.

Development ve Production Projelerini Ayırma

Development ile production aynı Firebase project'i paylaşırsa test user, yanlış data mutation ve Security Rules denemeleri gerçek kullanıcı verisini etkileyebilir. Ayrı project kullanmak IAM, billing, data ve Rules rollout sınırlarını daha güvenli hale getirir. Staging gerekiyorsa production'a yakın config ve test verisiyle üçüncü environment oluşturulabilir. Firebase CLI alias ile hangi project'e deploy edildiği açık biçimde yönetilebilir. CI pipeline production deployment için branch, approval ve project ID kontrolü yapmalıdır.

Firebase Config İçindeki API Key Secret mıdır?

Firebase Web Config içindeki Firebase hizmetlerine ait API key klasik server secret gibi değerlendirilmez, çünkü bu key esas olarak project veya app tanımlamak ve ilgili API çağrılarını doğru project'e yönlendirmek için kullanılır. Firebase'in güncel resmi dokümantasyonu Firebase API key'lerinin public by design olduğunu, data authorization'ın Security Rules, IAM ve App Check gibi mekanizmalarla sağlandığını açıkça belirtiyor. Buna rağmen key restrictions uygulanmalı ve aynı key Firebase dışı veya farklı hassas Google API'leri için kullanılmamalıdır. Özellikle Generative Language API gibi farklı hizmet anahtarlarının public Firebase config içine konmaması gerekir. Güvenlik stratejisi API key'i gizlemek üzerine kurulursa gerçek access control açık kalabilir. :contentReference[oaicite:15]{index=15}

Firebase Web Config Neden Client'ta Bulunur?

Web uygulaması Firestore, Authentication veya Realtime Database gibi Firebase servislerinin hangi project ile iletişim kuracağını bilmek zorundadır. Bu nedenle project ID, app ID ve Firebase API key gibi config bilgileri bundle içinde görülebilir. Bu değerlerin görünür olması database'in herkese açık olduğu anlamına gelmez. Gerçek read ve write authorization Security Rules üzerinden uygulanır. Source code içinde config görünmesini engellemek için environment variable kullanmak organization açısından faydalı olabilir, ancak bunu security boundary olarak görmek doğru değildir.

API Key'in Rolü

Firebase API key request'i doğru project ile ilişkilendirmeye ve quota veya billing bağlamını belirlemeye yardımcı olur. Güncel dokümantasyona göre Firebase tarafından otomatik oluşturulan yeni key'ler Firebase ile ilişkili API listesine restriction uygulanmış şekilde gelir. Key'i public alanda gören biri yine Security Rules tarafından izin verilmeyen database verisini okuyamaz. Ancak key quota abuse girişimlerinde kullanılabileceği için API restriction ve App Check gibi kontroller önemlidir. Firebase dışındaki API'ler için ayrı ve doğru şekilde restricted key kullanılmalıdır. :contentReference[oaicite:16]{index=16}

Güvenliği Sağlayan Asıl Katmanlar

Firebase client access güvenliği tek bir config secret'a bağlı değildir. Authentication user identity sağlar, Security Rules resource authorization ve data validation uygular, App Check ise request source abuse riskini azaltır. Backend tarafında Admin SDK kullanılıyorsa IAM ve server-side authorization ayrıca devreye girer. Bu katmanlar birlikte çalıştığında public client config doğal hale gelir. Ekiplerin security review sırasında “API key repo'da mı?” sorusundan önce “Rules hangi user'a hangi resource'u açıyor?” sorusunu sorması daha değerlidir.

Authentication

Authentication login yapan user'a doğrulanabilir identity ve token sağlar. Rules request.auth veya Realtime Database tarafında auth üzerinden UID ve claim bilgisine ulaşabilir. User signed in olduğu için bütün data'ya erişim verilmemelidir. Guest, owner, editor ve admin gibi access düzeyleri ayrı policy olarak tanımlanmalıdır. Backend endpoint de gelen ID token'ı doğrulamadan yalnız client tarafından gönderilen UID değerine güvenmemelidir.

Security Rules

Security Rules client request'in server tarafında allow veya deny edilmesini sağlar. Firestore Rules document path, auth, resource ve incoming data üzerinden policy tanımlayabilir. Realtime Database Rules path hierarchy, auth, data ve newData gibi değerleri kullanabilir. Rules source control içinde test edilebilir code olarak tutulmalıdır. Production'da test mode veya geniş allow bırakmak Firebase config gizli olsa bile sistemi güvensiz hale getirir.

App Check

App Check valid attestation token taşımayan client isteklerini desteklenen servislerde reject edecek şekilde enforcement sunabilir. Web tarafında yeni integration için reCAPTCHA Enterprise güncel Firebase tavsiyesidir. Enforcement öncesinde metrics izlenmesi gerçek client'ların token alıp alamadığını anlamaya yardımcı olur. Authentication ve Security Rules yine gerekli olmaya devam eder. Local development ile CI için debug provider token'ları kontrollü biçimde yönetilmelidir. :contentReference[oaicite:17]{index=17}

Hangi Credentials Kesinlikle Client'a Konmamalıdır?

Client bundle içine service account private key, Admin SDK privileged credential, backend secret, ödeme sağlayıcı secret veya Firebase dışı private API key kesinlikle konmamalıdır. Browser veya mobil binary kullanıcı tarafından incelenebilir ve içine gömülen secret güvenli kabul edilemez. Privileged credential Cloud Functions, Cloud Run, secret manager veya güvenilir backend environment içinde tutulmalıdır. Client server'a auth ID token gönderir, server token'ı doğrular ve gerekli privileged operation'ı kendi credential'ıyla yapar. “Environment variable kullandım” ifadesi client-side bundle'a compile edilen secret'ı güvenli hale getirmez.

Service Account Private Key

Service account private key Google Cloud veya Firebase kaynaklarına geniş yetki verebilecek hassas credential'dır ve client uygulamasına asla konmamalıdır. Repository'ye yanlışlıkla commit edilirse key revoke edilip yenisi oluşturulmalı ve erişim logları incelenmelidir. Managed cloud environment'larda mümkün olduğunda long-lived key dosyası yerine workload identity veya application default credential yaklaşımı tercih edilmelidir. Admin SDK server tarafında bu trusted credential üzerinden çalışır. Client yalnız kendisine ait user token ile sınırlı erişim elde etmelidir.

Firebase Authentication Nasıl Çalışır?

Firebase Authentication kullanıcı credential'ını ilgili provider akışıyla doğrular ve başarılı oturum sonrasında user object ile token tabanlı session oluşturur. Firebase ID token kullanıcı kimliğini ve bazı claim bilgilerini taşır, refresh token ise yeni ID token alınmasını sağlar. Güncel resmi dokümantasyona göre ID token yaklaşık bir saatlik kısa ömre sahiptir ve refresh token kullanıcı silinmesi, disable edilmesi veya önemli account değişiklikleri gibi durumlara kadar uzun süre kullanılabilir. Backend, client'tan gelen ID token'ı Admin SDK ile doğrulayarak UID ve custom claim bilgilerine ulaşabilir. Session security gerekiyorsa refresh token revoke ve revoked token kontrolü uygulanabilir. :contentReference[oaicite:18]{index=18}

User

User Firebase Authentication içinde kimliği doğrulanmış account temsilidir. Email, provider data, UID ve verification state gibi bilgiler taşıyabilir. User object client UI için yararlıdır, ancak authorization kararı yalnız client object'e güvenilerek verilmemelidir. Backend token verify ederek trusted identity elde etmelidir. Account disable veya delete edildiğinde session lifecycle ayrıca yönetilmelidir.

UID

UID kullanıcıyı Firebase project içinde benzersiz tanımlayan temel identity anahtarıdır. User-specific document path veya ownership field tasarımında sık kullanılır. Client'ın request body içinde gönderdiği UID tek başına güvenilir değildir, çünkü kullanıcı başka bir UID yazabilir. Security Rules içinde UID auth token'dan alınmalı veya backend verified token içindeki UID kullanılmalıdır. Resource path ile request.auth.uid eşleştirmek owner access için basit ve güçlü pattern'dir.

ID Token

ID token Firebase Authentication tarafından sign-in sonrasında oluşturulan JWT tabanlı kısa ömürlü kimlik token'ıdır. Backend request sırasında Authorization header içinde gönderilebilir ve Admin SDK ile doğrulanabilir. Token içinde UID, provider ve custom claim bilgileri bulunabilir. Token payload'ını client'ın decode etmesi UI için bilgi sağlayabilir, ancak server signature doğrulaması yapılmadan authorization için güvenilmemelidir. Token expiry ve gerektiğinde revocation kontrolü backend security policy'nin parçasıdır.

Refresh Token

Refresh token kullanıcı tekrar credential girmeden yeni ID token almayı sağlar ve session'ın uzun süre devam etmesine yardımcı olur. Firebase güncel session dokümantasyonu refresh token'ın kullanıcı silinmesi, disable edilmesi veya password ve email gibi önemli account değişikliklerinde geçersizleşebildiğini belirtiyor. Admin SDK ayrıca refresh token revoke etmeye imkan verir. Şüpheli session veya credential theft durumunda revocation kullanışlıdır. Client storage güvenliği platforma göre ayrıca değerlendirilmelidir. :contentReference[oaicite:19]{index=19}

Authentication State

Authentication state uygulamanın user login olup olmadığını ve hangi account'ın aktif olduğunu bilmesini sağlar. Web SDK'da onAuthStateChanged() gibi listener'lar initialization sırasında mevcut session state'ini bildirir. Route guard bu state kesinleşmeden “logged out” varsayarsa ekran flash veya yanlış redirect oluşabilir. Bu nedenle initial loading state ayrı tutulmalıdır. UI role görünürlüğü auth state'ten sonra hesaplanabilir, ancak data access Rules tarafından ayrıca korunmalıdır.

Token Lifecycle

ID token kısa ömürlüdür ve Firebase SDK gerektiğinde refresh token üzerinden yeni token alabilir. Custom claim değişikliği mevcut token'a anında yansımayabilir, yeni ID token issue edildiğinde görünür hale gelir. Client zorla refresh çağrısı yapabilir, ancak role assignment backend tarafından tamamlandıktan sonra bunu kontrollü kullanmak gerekir. Backend expiry ve gerekirse revoked token kontrolü yapmalıdır. Token lifecycle bilinmeden custom claim update sonrası “neden admin görünmüyor?” gibi hatalar sık yaşanır.

Firebase Authentication Yöntemleri

Firebase Authentication farklı kullanıcı deneyimlerine uygun çok sayıda sign-in yöntemi sağlar ve bir projede birden fazla provider birlikte kullanılabilir. Email-password klasik yöntemdir, federated provider'lar kullanıcıya mevcut account ile giriş kolaylığı sunar, anonymous authentication ise account oluşturmadan geçici identity sağlar. Custom Authentication mevcut enterprise identity veya kendi authentication backend'inizle Firebase session üretmek için kullanılabilir. Provider seçerken yalnız geliştirici kolaylığı değil account recovery, MFA, email verification ve account linking senaryoları da düşünülmelidir. Kullanıcı aynı email ile farklı provider üzerinden geldiğinde account merge politikası net olmalıdır.

Email ve Password

Email ve password yöntemi kullanıcı account'ını Firebase Authentication içinde yönetmeyi sağlar. Email verification açılması özellikle role veya organization erişimi email domain gibi signal'lara bağlanıyorsa önemlidir. Password reset ve account recovery akışı production öncesinde test edilmelidir. UI'da user signed in görünse bile email verified şartı Rules veya backend policy'de ayrıca kontrol edilebilir. High-risk uygulamalarda MFA ve suspicious session stratejisi değerlendirilmelidir.

Google

Google provider OAuth tabanlı sign-in akışıyla user'ın mevcut Google account'ını kullanmasına imkan verir. Web popup veya redirect akışı browser restriction ve mobile behavior açısından test edilmelidir. Provider sign-in sonrasında Firebase user UID oluşturur veya linked account'a bağlanır. Google account login başarılı olması application authorization anlamına gelmez. Organization membership veya role bilgisi ayrıca kontrol edilmelidir.

Apple

Apple sign-in özellikle iOS ekosisteminde güçlü kullanıcı deneyimi sağlar ve bazı platform policy senaryolarında gerekli olabilir. Apple user email relay veya first-login profile bilgisi gibi özel davranışlar account modeline dahil edilmelidir. Firebase user identity provider credential üzerinden oluşturulur. Role ve resource ownership yine Security Rules veya backend policy üzerinden uygulanır. Account deletion ve Apple token lifecycle product requirement'larıyla birlikte test edilmelidir.

GitHub

GitHub provider developer-oriented ürünlerde mevcut GitHub identity üzerinden giriş kolaylığı sağlayabilir. OAuth application configuration, redirect domain ve provider secret Firebase console tarafında doğru yönetilmelidir. GitHub organization membership gerekiyorsa bu bilgi yalnız client claim üzerinden varsayılmamalı ve güvenilir server entegrasyonuyla doğrulanmalıdır. Firebase Authentication yalnız provider sign-in sonucunda user identity sağlar. Project-specific authorization uygulama katmanının sorumluluğudur.

Microsoft

Microsoft provider kurumsal kullanıcıların mevcut organization account'larıyla sign-in yapmasını kolaylaştırabilir. Tenant-specific veya multi-tenant identity gereksinimleri OAuth configuration ve backend authorization modeliyle birlikte düşünülmelidir. User Microsoft account'a sahip olduğu için uygulamadaki organization'a otomatik erişim verilmemelidir. Membership database veya trusted claim üzerinden açık biçimde kontrol edilmelidir. Enterprise login akışında disabled account ve revoked access senaryoları ayrıca test edilmelidir.

Phone

Phone authentication SMS tabanlı sign-in sağlar ve kullanıcı deneyimi açısından kolay olabilir, ancak SMS abuse, quota ve account recovery riskleri dikkate alınmalıdır. Phone number tek başına yüksek güvenlik gerektiren uygulamalar için yeterli factor olarak değerlendirilmemelidir. App Check ve abuse protection yardımcı katmanlar olabilir. Kullanıcının phone number değişikliği account ownership süreçleriyle uyumlu olmalıdır. SMS maliyeti ve bölgesel delivery davranışı production monitoring içinde izlenmelidir.

Anonymous Authentication

Anonymous authentication kullanıcıya signup formu göstermeden Firebase UID oluşturup geçici data ownership sağlamaya yardımcı olur. Shopping cart, onboarding veya demo state gibi senaryolarda kullanışlıdır. Kullanıcı daha sonra gerçek provider ile account link ederek aynı UID veya data continuity korunabilir. Anonymous account'lar cleanup ve abuse strategy gerektirir. Sensitive resource veya privileged role anonymous identity'ye verilmemelidir.

Custom Authentication

Custom Authentication mevcut identity sisteminizde doğrulanmış user için trusted backend'in Firebase custom token üretmesini sağlar. Client bu custom token ile Firebase Authentication session açabilir. Token üretme yetkisi yalnız secure backend ortamında olmalıdır. Custom claim ve UID mapping enterprise identity ile Firebase resource access arasında köprü kurabilir. Authentication external sistemde olsa bile Firestore veya Realtime Database authorization yine Rules üzerinden uygulanmalıdır.

Authentication State Nasıl İzlenir?

Authentication state izleme uygulamanın initial session restore, login, logout ve token refresh davranışlarını doğru yönetmesine yardımcı olur. Web tarafında onAuthStateChanged() user'ın signed-in veya signed-out durumunu gözlemlemek için temel yöntemlerden biridir. UI ilk render'da user null kabul edip protected route'u hemen redirect etmemeli, Firebase mevcut session'ı kontrol edene kadar loading state gösterebilmelidir. Authentication state değişikliği data listener lifecycle'ıyla da koordineli olmalıdır. Logout olduğunda user-specific Firestore veya Realtime Database listener'ları kapatılmalıdır.

onAuthStateChanged()

onAuthStateChanged() auth instance üzerindeki user state değişikliklerini callback ile bildirir. İlk callback mevcut persisted session restore edildikten sonra user veya null ile gelebilir. React gibi framework'te subscription component lifecycle içinde kurulmalı ve cleanup edilmelidir. Callback içinde her state değişiminde aynı listener'ı tekrar tekrar açmamak gerekir. User değiştiğinde eski UID'ye bağlı data subscription kapatılıp yeni UID scope'una geçilmelidir.

Loading State

Initial authentication loading state sign-in ekranı ile authenticated ekran arasında doğru geçiş sağlar. Firebase persisted session'ı kontrol ederken user state henüz bilinmiyorsa route redirect yapılmamalıdır. Aksi halde kullanıcı protected page'i kısa süre görüp login'e atılabilir ve hemen geri dönebilir. Loading indicator mümkün olduğunca kısa ve erişilebilir olmalıdır. Authentication state belli olduğunda route decision tek seferde verilmelidir.

Signed-In User

Signed-in user object UID ve basic profile bilgilerini UI'a sağlar. User-specific query bu UID ile oluşturulabilir, ancak Rules yine server-side ownership doğrulaması yapmalıdır. Role custom claim içinden UI visibility için okunabilir. Claim değişikliği token refresh olmadan güncel olmayabilir. Critical permission check client role state yerine server veya Rules tarafından yapılmalıdır.

Logout

Logout yalnız auth session'ı kapatmak değil user-specific local state, listener ve hassas cache stratejisini de yönetmek anlamına gelir. Firestore persistent cache shared device üzerinde kalabileceği için sensitive uygulamada logout sonrası persistence politikası dikkatle tasarlanmalıdır. UI memory store temizlenmelidir. Data listener unsubscribe çağrıları tamamlanmalıdır. Başka user aynı cihazda login olursa önceki user verisinin yanlışlıkla gösterilmemesi test edilmelidir.

Route Protection

Route protection kullanıcının authentication state'ine göre page erişimini yönlendirir, ancak gerçek data güvenliği yalnız router guard ile sağlanamaz. Kötü niyetli user route kodunu atlayıp doğrudan database request gönderebilir. Protected route UX ve navigation control sağlar, Security Rules ise resource erişimini enforce eder. Admin route için client claim üzerinden menu göstermek mümkündür. Admin data read ve write yine Rules veya backend authorization ile korunmalıdır.

Authentication ile Yetkilendirme Neden Aynı Şey Değildir?

Authentication kullanıcı kimliğini doğrular, yetkilendirme ise doğrulanmış kullanıcının hangi data veya operation üzerinde izin sahibi olduğunu belirler. Bütün authenticated user'lara bütün collection'ı açmak en yaygın Firebase güvenlik hatalarından biridir. Kullanıcı login olmuş olabilir ama yalnız kendi profile document'ını okuyabilmelidir. Kurumsal sistemde organization, project veya role bazlı ek sınırlar gerekir. Default-deny ile başlayıp gerekli minimum izinleri açıkça tanımlamak daha güvenli ve denetlenebilir bir model oluşturur.

Login Olmuş Kullanıcı Her Veriyi Okumamalıdır

request.auth != null yalnız user sign-in olmuş mu sorusunu cevaplar. Eğer rule tüm users collection read erişimini bu koşulla açıyorsa herhangi bir authenticated user başka kullanıcıların document'larını okuyabilir. Bunun yerine path UID ile auth UID eşleştirilebilir veya organization membership kontrol edilebilir. Public data ile private data farklı document veya collection içinde ayrılmalıdır. Authorization testinde “different user” senaryosu mutlaka bulunmalıdır.

Resource Ownership

Resource ownership belirli document veya node'un hangi user'a ait olduğunu tanımlar. Ownership path ID üzerinden veya document içindeki ownerId alanı üzerinden modellenebilir. Create sırasında user yalnız kendi UID'sini owner yapabilmeli, update sırasında owner alanını başka UID'ye değiştirememelidir. Delete işlemi ayrıca owner veya admin policy ile sınırlandırılabilir. Ownership tek başına multi-tenant membership ihtiyaçlarını çözmeyebilir ve organization context ile birleştirilebilir.

Role-Based Authorization

Role-based authorization user'ı user, editor, moderator veya admin gibi role gruplarına ayırır. Her role için read, create, update ve delete permission matrix hazırlanabilir. Role custom claim içinde veya trusted database document'ında saklanabilir. Custom claim küçük access-control bilgisi için uygundur, ancak profile data için kullanılmamalıdır. UI role göre action gösterebilir fakat güvenlik enforcement Rules veya backend üzerinde kalmalıdır.

Attribute-Based Authorization

Attribute-based authorization yalnız user role'ünü değil resource ve context attribute'larını da kullanır. Örneğin user bir organization'ın member'ıysa ve document aynı organization ID'ye sahipse read yapılabilir. Project status, document sensitivity veya membership type ek condition olabilir. Bu model RBAC'den daha esnek olmakla birlikte rule okunabilirliğini korumak için helper function ve test matrix gerektirir. Authorization logic büyüdükçe data model access pattern'e göre yeniden düzenlenebilir.

Default-Deny Yaklaşımı

Default-deny hiçbir explicit allow condition karşılanmadığında request'in reddedilmesi prensibidir. Firebase Security Rules zaten erişimi açıkça izin vermediğiniz durumda deny edecek şekilde tasarlanabilir. Development sırasında test mode kullanılsa bile production'a geçmeden önce minimum required access tanımlanmalıdır. Broad wildcard allow kullanıp child path'te deny etmeye çalışmak özellikle Realtime Database cascading behavior nedeniyle tehlikelidir. Security review her yeni collection veya path için “kim okuyabilir, kim yazabilir?” sorusunu cevaplamalıdır.

Firebase Security Rules Nedir?

Firebase Security Rules client SDK üzerinden gelen database ve storage request'lerine server tarafında uygulanan declarative access control politikalarıdır. Rules authentication durumunu, resource ownership'i, incoming data'yı ve bazı query koşullarını inceleyerek operation'a izin verebilir veya reddedebilir. Bu yapı frontend code içindeki permission check'ten farklıdır, çünkü client rule dosyasını değiştiremez ve enforcement Firebase backend üzerinde gerçekleşir. Rules yalnız authorization değil data validation için de kullanılabilir. Production projelerinde Rules source control, code review, Emulator test ve CI deployment sürecinin parçası olmalıdır.

Client-Side Database Erişiminin Güvenlik Katmanı

Client doğrudan Firestore veya Realtime Database'e request gönderdiğinde arada sizin REST controller'ınız olmayabilir. Bu nedenle Security Rules client request'in gerçek güvenlik boundary'sidir. UI'da hidden button veya route guard yalnız presentation davranışını kontrol eder. Bir saldırgan SDK yerine REST veya custom script kullanabilir ve Rules yine server tarafında request'i değerlendirmelidir. Rules açık bırakılırsa frontend obfuscation database'i korumaz.

Server-Side Enforcement

Security Rules Firebase server infrastructure üzerinde evaluate edildiği için istemcinin local code değişikliğiyle bypass edilemez. Firestore client library veya Realtime Database client SDK aynı policy'ye uymak zorundadır. Bunun önemli istisnası privileged server SDK kullanımıdır; Firestore server client libraries Security Rules'u bypass eder ve IAM üzerinden çalışır. Bu nedenle backend kodunda authorization ayrıca uygulanmalıdır. Rules yalnız client SDK request'lerinin güvenliğini otomatik çözer. :contentReference[oaicite:20]{index=20}

Read Authorization

Read authorization hangi user'ın hangi document, collection query veya Realtime Database path'ini okuyabileceğini belirler. User-specific data için UID match kullanılabilir. Multi-tenant sistemde request user'ının tenant membership'i ve resource tenant ID'si birlikte kontrol edilebilir. Firestore query rule condition ile uyumlu constraint taşımak zorundadır. Sensitive field farklı permission gerektiriyorsa ayrı document'ta tutulması gerekebilir.

Write Authorization

Write authorization create, update ve delete operasyonlarını aynı koşula bağlamak yerine farklı değerlendirebilir. Create sırasında owner ID auth UID'ye eşit olmalı, update sırasında immutable field değişmemeli ve delete yalnız owner veya admin'e açık olabilir. Incoming data Firestore'da request.resource.data, Realtime Database'de newData üzerinden incelenebilir. Valid schema enforcement frontend validation'ın güvenlik açısından tamamlayıcısıdır. Client form validation bypass edilse bile invalid write server tarafında reddedilmelidir.

Data Validation

Rules incoming document veya node'un required field, type, allowed enum ve immutable field koşullarını kontrol edebilir. Örneğin user create sırasında role: "admin" yazamamalıdır. Realtime Database .validate rule data structure ve value check için kullanılabilir. Firestore Rules field diff veya incoming data condition ile belirli alan değişikliklerini kısıtlayabilir. Validation business logic'in tamamını Rules'a taşımak anlamına gelmez, ancak güvenlik açısından kritik invariant'lar server enforcement altında olmalıdır.

Rules Kod Olarak Yönetilmeli mi?

Evet, production Security Rules console üzerinde unutulan manuel ayarlar yerine repository içinde version control ile tutulmalıdır. Pull request review authorization değişikliğinin code review almasını sağlar. Emulator Suite authenticated, unauthenticated, owner, different user ve admin testlerinin otomatik çalışmasına yardımcı olur. Staging deploy sonrası production rollout yapılabilir. Rule rollback strategy source control commit üzerinden daha güvenli yönetilir.

Realtime Database Security Rules Nasıl Çalışır?

Realtime Database Security Rules JSON tree path yapısına göre read, write, validate ve index davranışlarını tanımlar. .read ve .write erişim kararını, .validate incoming data yapısını, .indexOn ise query için index ipucunu yönetir. Rules içinde auth, mevcut data, yeni newData ve wildcard path değişkenleri kullanılabilir. En kritik behavior, read ve write izinlerinin parent path'ten child path'e cascade etmesidir. Parent path'te geniş allow verirseniz child path'te deny ile bu izni geri alamazsınız. :contentReference[oaicite:21]{index=21}

.read

.read belirli path veya altındaki verinin hangi koşulda okunabileceğini tanımlar. Condition auth UID, role veya resource ownership üzerinden yazılabilir. Parent path'te read true verilirse bütün child data da okunabilir hale gelebilir. User-specific data için rule mümkün olduğunca dar path'te tanımlanmalıdır. Query request parent seviyeden yapılıyorsa child rules'ın otomatik filtering yapmayacağı unutulmamalıdır.

.write

.write create, update ve delete dahil write request'lerinin kabul edilip edilmeyeceğini belirler. Operation type data.exists() ve newData.exists() gibi condition'larla ayrıştırılabilir. Owner create sırasında auth UID kontrol edilebilir. Update sırasında protected field değişiklikleri .validate veya condition üzerinden sınırlandırılabilir. Parent write allow bütün child write'ları açabileceği için broad rule kullanılmamalıdır.

.validate

.validate write access verildikten sonra resulting data structure'ın kabul edilebilir olup olmadığını kontrol eder. Required child, string type, numeric range veya enum value gibi invariant'lar uygulanabilir. Realtime Database dokümantasyonuna göre validate rules read ve write gibi cascade etmez; ilgili bütün validation condition'ların başarılı olması gerekir. Delete sırasında new value null olduğunda validation davranışı ayrıca dikkate alınmalıdır. Client form validation yerine geçmez, fakat güvenlik sınırı olarak server-side doğrulama sağlar. :contentReference[oaicite:22]{index=22}

.indexOn

.indexOn Realtime Database query'lerinde belirli child field üzerinde index tanımlamaya yardımcı olur. orderByChild() ile sık sorgulanan property rules içinde index olarak belirtilmezse performance warning veya yüksek bandwidth görülebilir. Index data security sağlamaz, yalnız query verimliliğini etkiler. Access rule ve query limitleri ayrıca yazılmalıdır. Production query pattern'leri profiler veya usage metrics ile gözlemlenmelidir.

auth

auth request'e ait Firebase Authentication bilgilerini temsil eder. User sign-in olmamışsa auth null olabilir. UID ve custom claim bilgileri authorization condition içinde kullanılabilir. Client tarafından gönderilen random UID yerine auth.uid trusted identity olarak kullanılmalıdır. Role custom claim varsa auth.token üzerinden erişilebilir.

data

data write öncesindeki mevcut database value'yu temsil eder. Existing owner ID veya immutable field kontrolü için kullanılabilir. Delete operation'da mevcut resource ownership'i doğrulamak için önemlidir. Data tree içinde parent veya child navigation yapılabilir. Çok uzak path'lere dependency eklemek rules okunabilirliğini ve data model coupling'ini artırabilir.

newData

newData write başarıyla uygulanırsa ortaya çıkacak yeni value'yu temsil eder. Create sırasında required field kontrolü, update sırasında owner field immutable condition ve delete sırasında existence behavior için kullanılabilir. Incoming data'nın yalnız client payload değil merge sonrası resulting state olduğuna dikkat edilmelidir. Validation bu state üzerinden yapılabilir. Security rule testleri malformed ve privilege-escalation payload'larını kapsamalıdır.

Wildcard Paths

Realtime Database rules içinde $userId veya $roomId gibi wildcard değişkenler dynamic child key'leri yakalar. User path'inde $userId === auth.uid kontrolü owner access için yaygın pattern'dir. Wildcard çok üst seviyede geniş allow ile birleştirilirse beklenmedik access oluşturabilir. Special child path ile wildcard rule overlap behavior test edilmelidir. Permission matrix her dynamic path için expected sonucu açık biçimde göstermelidir.

Realtime Database Rules Cascading Davranışı

Realtime Database Rules cascading behavior güvenlik tasarımında en çok yanlış anlaşılan alanlardan biridir. Read ve write rule parent path'te allow verirse bu izin child path'lere de yayılır ve daha derindeki deny kuralı erişimi geri alamaz. Firebase'in güncel resmi dokümantasyonu bu davranışı açık biçimde “shallower rules override deeper paths” olarak tanımlar. Bu nedenle root veya geniş collection seviyesinde authenticated user'a allow verip child düzeyinde özel kısıtlama beklemek güvenli değildir. Least-privilege rule mümkün olduğunca access boundary'nin gerçek path seviyesinde tanımlanmalıdır. :contentReference[oaicite:23]{index=23}

Parent Rule

Parent rule daha üst seviyedeki path için read veya write access tanımlar. Örneğin /users altında authenticated user'a read verilirse bütün user child data'sı erişilebilir hale gelebilir. Child profile üzerinde ayrı deny yazmak bu izni geri almaz. Parent rule yalnız gerçekten bütün subtree aynı permission'a sahipse kullanılmalıdır. Security review broad parent allow condition'larını özellikle işaretlemelidir.

Child Rule

Child rule parent'ta izin verilmemiş erişime daha dar scope'ta izin verebilir. Ancak parent path'te zaten read true varsa child read false bunu revoke edemez. Bu behavior Firestore explicit match modelinden farklıdır. Realtime Database migration yapan ekiplerin eski varsayımlarını yeniden kontrol etmesi gerekir. Emulator test farklı user ve parent query senaryolarını kapsamalıdır.

Üst Seviyede Verilen İzin Neden Geri Alınamaz?

Realtime Database read veya write access atomic path operation olarak değerlendirilir. Parent'ta izin verildiğinde database child node'ları aynı access kapsamı içinde görür. Bu tasarım rule evaluation modelinin temel davranışıdır ve child rule security override olarak çalışmaz. Data tree access boundary'ye göre bölünmezse güvenli rule yazmak zorlaşabilir. Bu nedenle public ve private data aynı geniş parent altında indiscriminately tutulmamalıdır.

Root-Level Allow Anti-Pattern

Root seviyesinde .read: auth != null veya .write: auth != null gibi geniş izinler production için ciddi risktir. Bütün authenticated user'lar bütün database subtree'sine erişebilir. Child path deny kuralları bu access'i geri alamaz. Test mode benzeri geniş rule development bittikten sonra kaldırılmalıdır. Root default deny bırakıp gerekli path'leri explicit açmak daha güvenlidir.

Least-Privilege Path Tasarımı

Least-privilege yaklaşımı her user veya role'e yalnız ihtiyacı olan path üzerinde minimum read ve write yetkisi verir. Private user data /users/{uid}, shared room data /rooms/{roomId} ve admin-only data ayrı top-level path'lere ayrılabilir. Bu data model Rules yazmayı daha anlaşılır kılar. Query istemci tarafında erişim sınırıyla aynı path structure'ı takip eder. Permission test matrix her path için guest, user, owner ve admin sonuçlarını doğrular.

Firestore Security Rules Nasıl Çalışır?

Firestore Security Rules document path pattern'lerine göre request authorization ve data validation sağlar. Rules version 2 modern recursive wildcard behavior ve collection group query senaryoları için yaygın başlangıçtır. match resource path'i, allow operation ve condition'ı tanımlar; request.auth identity, resource.data mevcut document ve request.resource.data incoming document state'ini gösterir. Custom functions tekrar eden condition'ları okunabilir hale getirebilir. Server client library Firestore Rules'u bypass ettiği için backend IAM ve authorization ayrıca yönetilmelidir. :contentReference[oaicite:24]{index=24}

rules_version = '2'

rules_version = '2' Firestore rules language'in güncel yaygın sürümünü seçer ve özellikle recursive wildcard semantics bakımından version 1'den farklı davranış sunar. Yeni rules dosyalarında version declaration başta açık biçimde bulunmalıdır. Collection group query veya nested path design yapılırken version davranışı ekibin tamamı tarafından bilinmelidir. Migration sırasında mevcut rule testleri yeniden çalıştırılmalıdır. Version control commit'i behavior değişikliğini belgeler.

match

match hangi database path pattern'inin rule block tarafından kontrol edildiğini tanımlar. /users/{userId} gibi dynamic segment kullanılabilir. Nested match ile subcollection access ayrı yazılabilir. Parent document'a verilen permission subcollection'ı otomatik olarak aynı şekilde açmaz. Bu explicit structure data security sınırını daha görünür hale getirir.

allow

allow read, get, list, create, update veya delete gibi operation'ın hangi condition sağlandığında izinli olduğunu tanımlar. Read'i get ve list olarak ayırmak query behavior'ını daha kontrollü yönetebilir. Write'i create, update ve delete olarak ayırmak ownership invariant'larını korumaya yardımcı olur. Bir condition true ise request izin alabilir. Rule set içinde beklenmedik başka allow condition geniş access vermemelidir.

request.auth

request.auth authenticated request'in user identity ve token bilgilerini taşır. Unauthenticated request'te null olabilir. UID owner comparison için kullanılabilir. Custom claim role bilgisi request.auth.token üzerinden okunabilir. Client'ın body içindeki role alanı authorization için güvenilir kabul edilmemelidir.

resource.data

resource.data read veya update sırasında mevcut Firestore document'ın alanlarını gösterir. Existing owner ID, tenant ID veya immutable state kontrolü için kullanılır. Delete operation'da resource ownership'i doğrulamak mümkündür. Sensitive permission data document içinde tutuluyorsa user'ın bunu değiştiremeyeceği ayrıca garanti edilmelidir. Permission check için çok sayıda cross-document get() kullanımı rules limits ve maliyet davranışı açısından planlanmalıdır.

request.resource.data

request.resource.data write uygulanırsa ortaya çıkacak yeni document state'ini temsil eder. Create sırasında required field ve owner condition doğrulanabilir. Update sırasında existing resource ile karşılaştırılıp immutable field değişikliği engellenebilir. User kendi role veya tenant ID değerini yükseltememelidir. Server timestamp veya allowed enum gibi schema condition'ları aynı seviyede kontrol edilebilir.

Custom Functions

Custom Rules functions isSignedIn(), isOwner() veya isAdmin() gibi tekrar eden condition'ları merkezi ve okunabilir hale getirebilir. Firebase dokümantasyonuna göre functions sınırlı domain-specific language içinde çalışır, recursive çağrı yapamaz ve belirli call depth limitlerine sahiptir. Function içinde external service çağrısı yapılamaz. Helper function'ın adı policy niyetini açık anlatmalıdır. Her function branch emulator testleriyle doğrulanmalıdır. :contentReference[oaicite:25]{index=25}

Kullanıcıya Özel Veri Erişimi Nasıl Tasarlanır?

Kullanıcıya özel veri erişimi tasarımında en kolay kontrol modeli UID'yi resource path veya immutable owner field ile bağlamaktır. User yalnız kendi path'ini okuyabilir ve yazabilir, başka UID için gönderilen request Rules tarafından reddedilir. Create, update ve delete izinleri ayrı düşünülmelidir çünkü user kendi document'ını oluşturabilse bile protected field'ları sonradan değiştirmemelidir. Admin veya support role gerekiyorsa ikinci allow condition trusted custom claim veya membership data üzerinden eklenebilir. Bu access model test edildiğinde kullanıcı “başka UID yazarsam ne olur?” senaryosu özellikle doğrulanmalıdır.

UID-Based Document Path

UID-based path, user document ID'sini Firebase Authentication UID ile aynı yapar. Örneğin /users/{uid} document'ı user profile kaynağı olabilir. Rule path değişkeni ile request.auth.uid eşleşmesini kontrol eder. Bu yapı owner lookup için ek field gerektirmez. Public profile ve private data farklı permission gerektiriyorsa ayrı document veya subcollection kullanılmalıdır.

users/{userId}

users/{userId} pattern'i dynamic user document'larını rule içinde yakalar. Read veya update condition request.auth != null && request.auth.uid == userId mantığıyla owner access sağlayabilir. Admin access ayrı trusted claim ile eklenebilir. Collection list query bütün users document'larını getirebileceği için list permission çok dikkatli verilmelidir. User directory gerçekten public değilse broad read açılmamalıdır.

Owner Kontrolü

Owner kontrolü path ID veya document field üzerinden yapılabilir. Path UID modelinde userId auth UID ile eşleştirilir. Shared resource document'ında ownerId field gerekli olabilir. Create sırasında owner field user tarafından başka UID seçilememelidir. Update sırasında existing owner ile incoming owner aynı kalmalıdır.

Başka Kullanıcının Verisine Erişimi Engelleme

Different-user test production authorization testlerinin en değerli senaryolarından biridir. User A kendi document'ını okuyabilirken User B'nin document ID'sini doğrudan request ettiğinde permission denied almalıdır. UI'da link görünmemesi yeterli değildir. REST veya SDK ile explicit malicious request emulator testinde çalıştırılmalıdır. Collection query de unauthorized document döndürebilecek şekilde yazılmışsa Firestore request tamamen reddedilmelidir.

Create, Update ve Delete'i Ayrı Yetkilendirme

Create operation'da resource henüz olmadığı için incoming document üzerinden owner ve required field doğrulanır. Update operation mevcut resource ile yeni state karşılaştırılarak owner, createdAt veya role gibi immutable alanların değişmediği kontrol edilir. Delete existing resource ownership veya admin role üzerinden sınırlandırılabilir. Tek allow write condition bütün bu farklı invariants'ı açık biçimde ifade etmeyi zorlaştırabilir. Ayrı rule path'leri code review ve test matrix'i daha anlaşılır hale getirir.

Resource Ownership Pattern

Resource Ownership Pattern her kaynağın hangi kullanıcı veya organization tarafından kontrol edildiğini açık biçimde tanımlar. Ownership path içinde tutulabilir, document field olarak saklanabilir veya multi-owner membership collection ile modellenebilir. Seçim query pattern, tenant modeli ve transfer ownership gereksinimine göre yapılmalıdır. En kritik güvenlik kuralı client'ın protected ownership field'ını keyfi biçimde değiştirememesidir. Create, update ve delete testleri ownership boundary'yi ayrı ayrı doğrulamalıdır.

Owner ID Document İçinde Tutulmalı mı?

Shared collection içinde bütün tasks document'ları bulunuyorsa ownerId field query ve authorization için faydalı olabilir. User kendi task'larını where("ownerId", "==", uid) ile sorgulayabilir. Rules query constraint ile aynı ownership condition'ı değerlendirir. Owner ID client create sırasında auth UID'ye eşit olmalıdır. Update ile owner transfer gerekiyorsa bu operation privileged backend'e taşınabilir.

UID Path'te Tutulmalı mı?

User-specific subtree modelinde UID path segment'i olarak tutulabilir. Bu yaklaşım /users/{uid}/items/{itemId} gibi güçlü ownership sınırı sağlar. Query yalnız current user subtree içinde çalışır ve cross-user access doğal olarak daha zor hale gelir. Collection group query gerekiyorsa tenant veya owner field yine gerekebilir. Veri modelini yalnız rule yazmayı kolaylaştırmak için değil gerçek query ihtiyaçlarıyla birlikte seçmek gerekir.

Create Sırasında Ownership

Create request user'ın başka bir kullanıcı adına resource üretmesine izin vermemelidir. Incoming owner ID request.auth.uid ile eşleşmelidir. Tenant-based resource create sırasında user'ın gerçekten ilgili organization member'ı olduğu da kontrol edilmelidir. Client tarafından gönderilen role veya membership field trusted source değildir. Privileged delegated create gerekiyorsa backend endpoint kullanmak daha güvenli olabilir.

Update Sırasında Owner Alanının Değişmesini Engelleme

Existing document owner ID ile incoming document owner ID karşılaştırılarak değişiklik engellenebilir. User başka field'ları güncellerken owner field sabit kalır. Admin ownership transfer gerekiyorsa explicit admin condition veya server-only function kullanılabilir. Generic update rule içinde client'ın owner değiştirmesine izin vermek privilege escalation oluşturabilir. Emulator testi owner field mutation denemesini içermelidir.

Delete Authorization

Delete operation resource artık yeni state içinde bulunmayacağı için existing resource.data üzerinden owner kontrolü yapılabilir. Owner delete hakkına sahip olabilir veya business requirement gereği yalnız admin delete yapabilir. Soft delete kullanılıyorsa status field'ını kimlerin değiştirebileceği ayrıca kısıtlanmalıdır. Cascade cleanup server-side function gerektirebilir. Audit gerektiren projelerde hard delete yerine retention policy ve tombstone yaklaşımı değerlendirilebilir.

Role-Based Access Control (RBAC)

RBAC kullanıcıları belirli role gruplarına ayırıp her role için permission set tanımlar. User, editor, moderator ve admin gibi role isimleri yalnız örnektir ve gerçek domain language'e göre belirlenmelidir. Permission matrix role'lerin read, create, update, delete ve privileged action yetkilerini açıklaştırır. Role custom claims içinde tutulabilir veya organization-specific role gerekiyorsa membership document üzerinden okunabilir. Client UI role'e göre action gösterebilir, ancak role enforcement Security Rules ya da backend tarafında yapılmalıdır.

User

User role çoğu uygulamada temel signed-in erişimi temsil eder. Kullanıcı kendi profile'ını, kendisine ait resource'ları veya membership bulunduğu organization verisini okuyabilir. Başka user'ın private kaynağına erişemez. Create operation belirli collection'larla sınırlı olabilir. Permission matrix içinde user role'ünün yapamayacağı işlemler de açıkça yazılmalıdır.

Editor

Editor role content veya project resource üzerinde update yetkisi alabilir, ancak user management ya da billing gibi privileged action'lara erişmemelidir. Resource scope global değil organization veya project membership ile sınırlandırılabilir. Editor role custom claim global uygulama rolü için kullanılabilir. Tenant-specific editor bilgisi membership document'ta tutulması daha uygun olabilir. Rule test different tenant editor access'ini reddetmelidir.

Moderator

Moderator role community content review, report handling veya limited user action gibi görevler üstlenebilir. Admin ile aynı yetkiye sahip olmamalıdır. Moderator'ın görebileceği sensitive user field'lar ayrı document path'te tutulabilir. Audit log önemli olabilir. UI moderator tool gösterse bile backend write authorization trusted role üzerinden yapılmalıdır.

Admin

Admin role geniş yetki taşıdığı için claim assignment yalnız privileged backend üzerinden yapılmalıdır. Client “role: admin” document update yaparak bu role'e geçememelidir. Admin custom claim Security Rules içinde kullanılabilir. Backend Admin SDK request'i Rules'u bypass ettiğinde admin action'ın kim tarafından yapıldığı ayrıca verify edilmelidir. Admin operation audit ve token revocation stratejisi security review'ın parçasıdır.

Permission Matrix

Permission matrix satırlarda resource veya operation, sütunlarda role olacak şekilde expected access'i belgeler. Guest, user, owner, editor, moderator ve admin için read, create, update ve delete sonuçları belirlenebilir. Bu tablo Security Rules test case'lerine dönüştürülebilir. Product requirement değiştiğinde rule ve test birlikte güncellenir. Matrix olmadan role isimleri hızla belirsiz hale gelir ve ekipler aynı role farklı anlam yükleyebilir.

Role Bilgisi Nerede Saklanmalı?

Global ve küçük access-control bilgisi custom claim içinde tutulabilir. Organization-specific role membership document'ta daha esnek olabilir çünkü user farklı organization'larda farklı role taşıyabilir. Custom claim güncellemesi token refresh gerektirir ve payload size sınırlıdır. Profile veya frequently changing business data claim içine konmamalıdır. Role storage seçimi access scope ve update frequency üzerinden yapılmalıdır.

Firebase Custom Claims Nedir?

Firebase Custom Claims authenticated user'ın ID token'ına eklenen ve access-control için kullanılabilen küçük trusted claim bilgileridir. Claim yalnız privileged server environment'da Admin SDK ile set edilmelidir. Firebase'in güncel dokümantasyonuna göre custom claims payload 1000 byte sınırına sahiptir ve profile data saklamak için tasarlanmamıştır. Claim değişikliği yeni ID token issue edildiğinde client'a yansır; kullanıcı tekrar login olabilir, token doğal refresh olabilir veya zorla refresh istenebilir. Security Rules request.auth.token veya Realtime Database tarafında auth.token üzerinden bu bilgiyi kullanabilir. :contentReference[oaicite:26]{index=26}

Claims Ne İçin Kullanılır?

Custom claims admin, moderator, premium veya application-level access flag gibi küçük authorization bilgileri için uygundur. Claim user profile açıklaması, avatar URL veya uzun organization listesi için kullanılmamalıdır. Her authenticated request ID token taşıdığı için gereksiz büyük claim performans ve token boyutunu etkiler. Access policy için gerekli minimal bilgi seçilmelidir. Multi-tenant membership çok değişkense database membership lookup daha uygun olabilir.

Admin SDK ile Claim Tanımlama

Custom claim set operation yalnız trusted backend ortamında Admin SDK ile yapılmalıdır. Client role yükseltme endpoint'ini doğrudan herkese açık biçimde çağırmamalıdır. Backend request yapan user'ın mevcut admin permission'ını doğruladıktan sonra target UID claim'ini güncelleyebilir. Firebase Admin SDK set operation mevcut custom claim object'i overwrite edebileceği için var olan claim'lerin korunması gerektiğinde merge logic dikkatle uygulanmalıdır. Claim assignment audit log'a yazılabilir. :contentReference[oaicite:27]{index=27}

ID Token İçinde Claims

Custom claims yeni ID token içinde signed payload olarak kullanıcıya iletilir. Client UI role badge veya navigation visibility için decoded claim bilgisini okuyabilir. Backend aynı ID token'ı verify ederek trusted claim değerine ulaşır. Client'tan ayrı JSON body ile gönderilen role: "admin" güvenilir değildir. Security Rules ID token içindeki claim'i trusted authorization signal olarak değerlendirebilir.

Security Rules'da Claims Kullanımı

Firestore Rules request.auth.token.admin == true gibi condition ile admin access tanımlayabilir. Realtime Database auth.token üzerinden benzer role condition kullanabilir. Claim global permission için uygundur. Tenant-specific role listesi token içine aşırı veri ekleyebilir. Rule test user claim setleriyle farklı access sonuçlarını doğrulamalıdır.

Token Refresh

Custom claim set edildiğinde mevcut client token anında değişmez. Firebase dokümantasyonuna göre yeni claim user sign-in olduğunda, mevcut token refresh edildiğinde veya client zorla getIdToken(true) çağırdığında yeni token'a geçer. Bu nedenle role update UI'da hemen görünmeyebilir. Backend claim update tamamlandıktan sonra client'a refresh signal gönderebilir. Security-sensitive downgrade durumunda refresh token revoke stratejisi ayrıca düşünülmelidir. :contentReference[oaicite:28]{index=28}

Custom Claims Profil Verisi İçin Neden Kullanılmamalı?

Custom claims her authenticated ID token içinde taşındığı için uzun profile data eklemek bütün authenticated request'leri gereksiz büyütür. Firebase resmi rehberi claims'i yalnız access control amacıyla kullanmayı ve diğer profile verilerini database veya başka storage içinde tutmayı öneriyor. Payload 1000 byte ile sınırlıdır. Profile data sık güncelleniyorsa token refresh yönetimi de gereksiz hale gelir. User display name, preferences veya organization metadata database document'ında tutulmalıdır. :contentReference[oaicite:29]{index=29}

Custom Claims ile Admin Yetkilendirme

Custom Claims admin, moderator veya premium gibi global access signal'ları için güçlü bir yöntemdir. Claim trusted backend tarafından atanır ve ID token içinde client ile Rules'a ulaşır. Security Rules claim condition üzerinden privileged resource'u açabilir. Client UI aynı claim'i action görünürlüğü için kullanabilir, ancak UI state'e güvenlik boundary'si muamelesi yapılmamalıdır. Role kaldırıldığında token lifecycle ve revocation gereksinimi security policy'ye göre yönetilmelidir.

Admin Claim

Admin claim örneğin {admin: true} gibi minimal boolean olabilir. Claim yalnız existing admin veya trusted deployment process tarafından atanmalıdır. Firestore Rules admin-only collection read veya write için condition kullanabilir. Backend verified token claim'ini kontrol ettikten sonra privileged operation yapabilir. Client local storage'a “admin=true” yazıp yetki kazanamamalıdır.

Moderator Claim

Moderator claim admin'den daha dar permission set'i temsil etmelidir. Content hide, report resolve veya limited user action gibi operation'larla sınırlandırılabilir. Rules operation veya path bazında moderator access tanımlar. Admin fallback condition ayrıca eklenebilir. Permission matrix moderator ile admin arasındaki farkı belgeler.

Premium Claim

Premium claim subscription status gibi access-control signal için kullanılabilir, ancak payment detail claim içinde tutulmamalıdır. Payment webhook güvenilir backend'de subscription doğruladıktan sonra claim güncelleyebilir. Client token refresh sonrasında premium feature UI görünür hale gelebilir. Backend premium resource request'inde verified token claim kontrol eder. Subscription expire olduğunda claim removal ve token refresh süreci planlanmalıdır.

Security Rules Enforcement

Security Rules client'ın claim bilgisini değiştirip değiştirmediğine bakmaz, Firebase tarafından signed ID token içindeki trusted claim'i kullanır. Admin resource için explicit allow condition yazılır. Default user path bundan ayrı kalır. Broad rule daha sonra admin rule ekleyerek daraltılamayacak bir access yaratmamalıdır. Emulator test token claim'lerini simüle ederek expected sonuçları doğrulamalıdır.

Client UI'da Role Kullanımı

Client role claim'i navigation item, admin button veya premium badge göstermek için kullanabilir. Bu UX açısından yararlıdır çünkü user erişemeyeceği action'ı görmez. Ancak button hidden olması security değildir. User request'i manuel olarak gönderebilir. Server tarafındaki Rules veya backend policy aynı permission'ı enforce etmelidir.

Client'taki Role Bilgisine Güvenmeme

Client JavaScript runtime user kontrolündedir ve local state değiştirilebilir. Developer tools ile variable role admin yapılabilir. Bu yalnız UI değiştirir, backend access değişmemelidir. Rules signed token claim'i veya trusted database membership'i kontrol eder. Backend verified token olmadan role parameter kabul etmemelidir.

RBAC mi ABAC mi?

RBAC role isimleri üzerinden permission verirken ABAC user, resource ve context attribute'larını birlikte değerlendirir. Basit application-wide admin ve user ayrımı RBAC ile kolay yönetilir. Multi-tenant veya project membership yapısında yalnız global role yeterli olmayabilir ve organization ID, membership state veya resource attribute gerekir. Gerçek sistemlerin önemli kısmında karma model kullanılır. Örneğin user global editor role'e sahip olabilir, ancak yalnız member olduğu organization içindeki document'ları düzenleyebilir.

Role-Based Access

Role-based access anlaşılır permission matrix ve basit rule condition sağlar. Admin, moderator ve editor gibi role'ler product language ile uyumlu olmalıdır. Global role custom claim içinde saklanabilir. Role sayısı arttıkça “role explosion” oluşabilir. Bu noktada attribute tabanlı membership daha esnek olabilir.

Attribute-Based Access

ABAC user'ın role'ü yanında tenant, project, resource owner ve document status gibi attribute'ları kullanır. User editor olabilir, ancak resource aynı project membership'ine ait değilse update yapamaz. Rule helper functions policy'yi okunabilir tutabilir. Attribute source client tarafından değiştirilebilir alanda tutuluyorsa protected write rule gerekir. Test matrix condition kombinasyonlarını kapsamalıdır.

Organization Membership

Organization membership user'ın hangi tenant'a erişebileceğini belirler. Membership document role, status ve join date gibi bilgiler içerebilir. Rules request user'ının ilgili organization membership'ini doğrulayabilir. Global claim içine yüzlerce organization ID koymak ölçekli değildir. Membership lookup veya path-based model daha uygun olabilir.

Project Membership

User aynı organization içinde yalnız belirli project'lere erişebilir. Project membership ayrı collection veya nested path'te tutulabilir. Query yalnız erişilen project scope'unda yapılmalıdır. Rules user'ın project membership document'ını kontrol edebilir. Admin global bypass gerektiğinde explicit claim condition eklenebilir.

Document Attributes

Document status, confidentiality veya owner ID authorization kararına dahil olabilir. Draft document yalnız creator tarafından okunabilirken published document daha geniş erişime açılabilir. User status field'ını kendi lehine değiştirememelidir. Incoming state validation bu nedenle önemlidir. Attribute-based condition product workflow ile birlikte test edilmelidir.

Karma Yetkilendirme Modeli

Karma model global role ile resource-specific membership'i birleştirir. Örneğin global admin bütün tenant'lara erişebilir, normal editor yalnız member olduğu tenant ve project içinde update yapabilir. Bu yaklaşım role sayısını azaltır. Rules helper function access policy'yi merkezi hale getirebilir. Backend ve client Rules aynı authorization sözlüğünü paylaşacak şekilde belgelenmelidir.

Multi-Tenant Firebase Yetkilendirmesi

Multi-tenant Firebase mimarisinde en önemli güvenlik hedefi bir tenant kullanıcısının başka tenant verisine hiçbir erişim elde edememesidir. Tenant ID resource path'te, document field'ında veya her ikisinde bulunabilir. User membership trusted document veya claim üzerinden doğrulanır. Query tenant constraint taşır ve Rules aynı constraint'i enforce eder. Tenant admin yalnız kendi tenant scope'unda privileged işlem yaparken global admin ayrı ve çok sınırlı bir role olarak tasarlanmalıdır.

Tenant ID

Tenant ID organization veya customer boundary'sini temsil eder. Data path /tenants/{tenantId}/projects gibi modellenebilir. Bu structure query ve rule scope'u doğal biçimde daraltır. User'ın request ettiği tenant ID membership record ile doğrulanmalıdır. Client route parameter tek başına trusted değildir.

Organization ID

Organization ID tenant boundary ile aynı anlamda kullanılabilir veya daha geniş business hierarchy içinde tenant alt birim olabilir. Document field olarak tutulduğunda query where("organizationId", "==", currentOrg) condition taşıyabilir. Incoming create request organization ID'yi user'ın member olduğu organization'a eşitlemelidir. Update sırasında field immutable olabilir. Admin transfer operation backend'e taşınabilir.

User Membership

User membership hangi UID'nin hangi tenant veya organization ile ilişkili olduğunu tanımlar. Membership document active, suspended, editor veya admin gibi status içerebilir. User kendi membership role'ünü değiştirememelidir. Invitation acceptance trusted flow ile create edilmelidir. Rules membership document read ve write permission'larını çok dar tutmalıdır.

Cross-Tenant Access'i Engelleme

Cross-tenant access test user A'nın tenant B resource ID'sini doğrudan request etmesiyle yapılmalıdır. Query scope ve direct document get ayrı test edilmelidir. Admin olmayan user farklı tenant ID yazdığında deny almalıdır. Rules yalnız UI selected tenant state'e güvenmemelidir. Backend endpoint de verified UID membership kontrolü yapmalıdır.

Tenant Admin

Tenant admin yalnız kendi organization resource'larında privileged operation yapmalıdır. Global admin claim vermek yerine membership document role tenantAdmin olabilir. Rules resource tenant ID ile membership tenant ID'yi eşleştirir. User management operasyonlarında hedef user'ın da aynı tenant'a ait olduğu kontrol edilir. Audit log tenant-scoped admin action'ları izlemelidir.

Global Admin

Global admin bütün tenant data'sına erişebilecek çok güçlü role'dür ve kullanıcı sayısı minimum tutulmalıdır. Claim assignment manual trusted process gerektirebilir. MFA, token revocation ve audit logging bu role için daha sıkı uygulanabilir. Client UI global admin dashboard gösterebilir. Backend ve Rules explicit global admin condition kullanmalıdır.

Tenant Bazlı Data Modeling

Tenant-specific collections root altında ayrı path'lerde tutulabilir. Bu structure cross-tenant query riskini azaltır ve Rules okunabilirliğini artırır. Global reporting gerekiyorsa server-side aggregate veya collection group query kullanımı ayrı authorization gerektirir. Tenant ID duplicate field query ihtiyacına göre eklenebilir. Data retention ve deletion tenant bazında uygulanabilir.

Security Rules ile Data Validation

Security Rules yalnız kimin data'ya erişeceğini değil incoming data'nın kabul edilebilir structure ve value taşıyıp taşımadığını da kontrol edebilir. Required field, data type, numeric range, immutable field ve enum gibi invariant'lar client validation'dan bağımsız server enforcement ile korunur. User kendi createdBy veya role alanını keyfi değiştirememelidir. Server timestamp gerektiren workflow'larda trusted timestamp pattern kullanılabilir. Validation testleri malformed payload yanında privilege escalation payload'larını da içermelidir.

Required Fields

Create sırasında document'ta bulunması gereken field listesi doğrulanabilir. Firestore rules incoming key set veya field existence üzerinden kontrol yapabilir. Realtime Database .validate child existence ile aynı amacı sağlar. Client eski version nedeniyle eksik field gönderirse write reddedilebilir. Schema migration backward compatibility planı bu nedenle önemlidir.

Data Type

Field string, number, bool veya list gibi beklenen type ile sınırlandırılabilir. Client UI yanlış type göndermese bile malicious request type confusion yaratabilir. Rules type validation business invariant'ı korur. Database'de mixed type oluşması query davranışını zorlaştırır. Migration sırasında eski data schema ile yeni Rules uyumu kontrol edilmelidir.

Minimum / Maximum Value

Rating, quantity veya pagination-related field belirli range içinde tutulabilir. Client negative quantity veya aşırı yüksek numeric value yazarak business logic'i bozamamalıdır. Rules simple min max condition uygulayabilir. More advanced domain calculation backend'e bırakılabilir. Validation failure user-friendly error mapping ile UI'a açıklanmalıdır.

Immutable Fields

CreatedAt, createdBy, ownerId veya tenantId gibi field'lar create sonrası değişmemelidir. Update rule existing ve incoming value'yu karşılaştırarak immutability sağlayabilir. Admin transfer operation gerekiyorsa explicit privileged path kullanılabilir. Generic update endpoint protected field'ı değiştirememelidir. Test invalid update'i doğrulamalıdır.

Enum Values

Status field yalnız draft, published veya archived gibi allowed value'lara sahip olabilir. User arbitrary string yazamamalıdır. Workflow transition yalnız enum validation ile değil mevcut state ile yeni state kombinasyonu üzerinden de sınırlandırılabilir. Örneğin archived resource doğrudan draft'a dönmeyebilir. Karma workflow backend logic gerektiriyorsa Rules minimum invariant'ı koruyabilir.

CreatedBy Alanını Korumak

Create sırasında createdBy auth UID ile eşleşmelidir. Update sırasında existing value ile incoming value aynı kalmalıdır. User başka user adına content oluşturamamalıdır. Backend delegated create gerekiyorsa privileged server operation kullanılır. Audit log user identity ve server action source'unu ayırabilir.

Server Timestamp Kontrolü

Client clock güvenilir olmadığı için createdAt veya updatedAt gibi alanlarda server timestamp tercih edilebilir. Firestore Rules request time ile incoming timestamp relationship kontrol edebilir. Realtime Database server timestamp sentinel kullanabilir. Offline write sırasında local estimated value kullanıcıya gösterilebilir. Server-confirmed state metadata ile ayrıştırılabilir.

Firebase Security Rules Filtre Değildir

Firestore Security Rules sorgu sonucunu belge belge filtreleyip yalnız erişilebilir document'ları döndüren mekanizma değildir. Firebase resmi dokümantasyonu sorguların “ya tamamen ya hiç” mantığıyla değerlendirildiğini açık biçimde belirtiyor. Query potansiyel olarak user'ın yetkisiz document'ını döndürebilecekse request reddedilir. Bu nedenle query constraints authorization condition ile aynı sınırı taşımalıdır. Data model, index ve Rules tasarımının birlikte yapılması Firebase güvenliğinin en önemli pratiklerinden biridir. :contentReference[oaicite:30]{index=30}

Query ile Authorization'ın Birlikte Tasarlanması

User yalnız kendi tasks document'larını okuyabiliyorsa query de ownerId == uid gibi constraint taşımalıdır. Rules aynı ownership condition'ı doğrular. Query bütün tasks collection'ını isteyip user'a ait olmayanları Rules'un atmasını bekleyemez. Bu yapı authorization ve query pattern'in birbirine bağlanmasına neden olur. Repository API bu safe query shape'i merkezi hale getirebilir.

Collection'ın Tamamını İsteyip Rules ile Filtreleme Yanılgısı

Client tasks collection'ın tamamını query ettiğinde result set içinde user'ın okuyamayacağı document olasılığı varsa Firestore request'i reddedebilir. Rules “izinli olanları döndür, diğerlerini gizle” şeklinde çalışmaz. Bu behavior security açısından data leak riskini azaltır. Developer permission denied hatasını Rules bug sanabilir. Gerçek çözüm query'nin authorization constraint'i taşımasıdır.

Query Constraints

Where, limit ve orderBy constraint'leri authorization modeline göre seçilmelidir. User tenant-specific data okuyorsa tenantId filter query'de bulunmalıdır. Rules query properties veya potential result set üzerinden access değerlendirebilir. Pagination cursor aynı tenant scope içinde kalmalıdır. Query builder unsafe combination üretmemelidir.

Data Model Etkisi

Authorization için gerekli field document'ta yoksa safe query yazmak zorlaşabilir. Owner ID veya tenant ID duplicate data olarak tutulabilir. Denormalization Firestore data modelinin doğal parçası olabilir. Protected field user tarafından değiştirilememelidir. Data model design meeting içinde permission matrix de incelenmelidir.

Index Tasarımı

Authorization constraint ile sort veya başka filter birleşince composite index gerekebilir. Index error geliştirme sırasında gerekli index'i oluşturmak için yönlendirme sağlayabilir. Production query matrix hangi index'lerin gerçekten kullanıldığını belgeler. Gereksiz index write maliyetini artırabilir. Security query shape ve index plan birlikte tutulmalıdır.

Cloud Firestore Gerçek Zamanlı Veri Nasıl Çalışır?

Firestore gerçek zamanlı veri erişimi snapshot listener üzerinden çalışır ve document, collection veya query sonucundaki değişiklikler client'a event olarak iletilir. onSnapshot() ilk bağlandığında mevcut state'i içeren initial snapshot verir ve daha sonra değişiklikler geldikçe yeni snapshot üretir. Listener offline cache ile de çalışabilir ve metadata server ile local state ayrımını gösterebilir. Geniş collection listener yerine user veya tenant scope'lu query listener kullanmak hem güvenlik hem maliyet açısından daha doğru olur. Component yaşam döngüsünde unsubscribe çağrısı yapılmalıdır.

onSnapshot()

onSnapshot() Firestore Web SDK'da document veya query realtime listener oluşturur. Callback snapshot içeriğini alır. Error callback permission denied veya network-related hata durumunu ele alabilir. Function'ın döndürdüğü unsubscribe reference component cleanup sırasında çağrılmalıdır. Listener lifecycle merkezi store içinde yönetiliyorsa duplicate subscription oluşmamasına dikkat edilmelidir.

Document Listener

Document listener tek resource değişikliklerini izlemek için en dar realtime erişim yöntemidir. User profile veya single task detail gibi senaryolarda kullanışlıdır. Document silinirse snapshot existence state değişir. Rules direct document read permission'ını değerlendirir. Listener artık gerekli değilse unsubscribe edilmelidir.

Collection Listener

Collection listener geniş result set'i realtime takip edebilir. Collection büyükse bütün document'ları dinlemek read ve render maliyeti oluşturabilir. Query filter ve limit kullanılmalıdır. User authorization tüm collection'ı okumaya izin vermiyorsa broad listener permission denied alabilir. Pagination ile realtime behavior product requirement'a göre tasarlanmalıdır.

Query Listener

Query listener yalnız filter ve order condition'larına uyan result set'i takip eder. User-owned veya tenant-scoped data için en güvenli patternlerden biridir. Rules query'nin yetkisiz result üretemeyeceğini doğrular. Index requirement ortaya çıkabilir. Result set change frequency maliyet ve UI update davranışını etkiler.

Initial Snapshot

Listener bağlandığında mevcut result set initial snapshot olarak gelir. Offline cache varsa ilk snapshot local cache'den gelebilir. UI loading state metadata veya snapshot arrival ile yönetilebilir. “İlk snapshot geldi, server kesin güncel” varsayımı offline durumda doğru olmayabilir. fromCache metadata bu ayrımı gösterebilir.

Incremental Updates

Snapshot docChanges() gibi API'lerle added, modified ve removed document değişikliklerini ayırt etmeye yardımcı olabilir. Büyük listeyi her event baştan render etmek yerine incremental update kullanılabilir. Framework state update batch edilebilir. Permission değişikliği listener error oluşturabilir. Cache ve server update ayrımı metadata üzerinden gösterilebilir.

Firestore Listener Nasıl Güvenli Tasarlanır?

Güvenli Firestore listener önce user'ın gerçekten erişebileceği query scope'u belirler ve Security Rules ile bu query'nin uyumunu doğrular. Listener error callback permission denied durumunu kullanıcıya uygun şekilde ele almalıdır. Component veya route kapandığında unsubscribe çağrısı yapılmalıdır. Auth user değiştiğinde eski UID veya tenant listener'ı devam etmemelidir. Realtime listener'ın sürekli açık olması yalnız data freshness değil read maliyeti ve client render davranışı açısından da izlenmelidir.

Kullanıcıya Göre Query

User-owned data query ownerId == currentUid condition taşıyabilir. Tenant data query current organization ID ile sınırlanabilir. UID veya tenant ID auth state'ten trusted context olarak alınmalıdır. Client URL parametresine göre farklı tenant query yapılırsa membership önce doğrulanmalıdır. Query helper bütün feature'larda aynı safe pattern'i kullanabilir.

Rules ile Query'nin Uyumlu Olması

Rules user'ın yalnız owner olduğu document'ları okuyabilmesine izin veriyorsa query de aynı condition'ı taşımalıdır. Firestore Rules filtre olmadığı için broad query reject edilir. Authorization change query builder testlerini de etkileyebilir. Emulator test gerçek query ile çalıştırılmalıdır. Permission condition ile composite index requirement birlikte doğrulanmalıdır.

Listener Error Callback

onSnapshot() error callback permission veya network error'larını yakalamak için kullanılmalıdır. Error sadece console'a yazılıp UI loading durumunda bırakılmamalıdır. Permission denied user role değişmiş veya query rules ile uyumsuz olabilir. Error observability sistemine context ile gönderilebilir. Sensitive document ID veya user data log içine gereksiz yazılmamalıdır.

Permission Denied

Permission denied her zaman “Firebase bozuk” anlamına gelmez. Query security condition taşımıyor olabilir, user token expired veya claim güncel olmayabilir. Rules deployment yanlış environment'a gitmiş olabilir. Emulator ve staging reproduction root cause bulmayı kolaylaştırır. UI user'a teknik rule detayını göstermeden uygun access mesajı vermelidir.

Listener Cleanup

Listener cleanup route veya component artık kullanılmadığında network subscription'ı sonlandırır. React useEffect return callback veya Flutter stream lifecycle gibi framework pattern'leri kullanılabilir. Auth change sırasında önce eski listener kapatılmalıdır. Duplicate listener aynı data için gereksiz read ve state update oluşturabilir. Memory profiler ve network log bu hatayı görünür hale getirebilir.

Unsubscribe

onSnapshot() tarafından dönen unsubscribe function listener'ı kapatır. Reference kaybolmamalıdır. Multiple listener listesi merkezi subscription manager ile yönetilebilir. Logout sırasında bütün user-specific subscription'lar kapatılabilir. Unsubscribe işlemi data cache'i otomatik temizlemek anlamına gelmez.

Firestore Snapshot Metadata

Firestore snapshot metadata local optimistic state ile server-confirmed state'i ayırmaya yardımcı olur. hasPendingWrites snapshot içindeki değişikliğin henüz backend tarafından onaylanmamış local write içerip içermediğini gösterebilir. fromCache data'nın server yerine local cache'den geldiğini bildirir. includeMetadataChanges yalnız metadata değişikliklerinde de callback almak için kullanılabilir. Bu bilgiler offline-first kullanıcı deneyiminde “kaydediliyor”, “offline” veya “senkronize edildi” gibi durumları doğru göstermek için değerlidir.

hasPendingWrites

hasPendingWrites local write henüz backend'e commit edilmediyse true olabilir. UI optimistic biçimde yeni değer gösterirken küçük sync indicator sunabilir. Server Security Rules write'ı reddederse SDK local state'i uygun şekilde reconcile eder ve error handling gerekir. User “kaydedildi” mesajını server onayı gelmeden kesin biçimde görmemelidir. Critical transaction'larda backend-confirmed state beklenebilir.

fromCache

fromCache snapshot'ın server yerine local cache'den geldiğini gösterir. Offline durumda cached data stale olabilir. UI data'yı kullanmaya devam edebilir, ancak connectivity veya freshness indicator göstermek faydalı olabilir. Güncel Firebase offline rehberi bu metadata'yı cache ve server state ayrımı için öneriyor. Persistent cache hassas data içeriyorsa shared device policy ayrıca uygulanmalıdır. :contentReference[oaicite:31]{index=31}

includeMetadataChanges

Default listener yalnız metadata değişikliğinde her zaman yeni event vermeyebilir. includeMetadataChanges option metadata transition'larını callback'e dahil eder. Bu sayede pending write server-confirmed olduğunda UI sync state güncellenebilir. Çok sık metadata event gereksiz render oluşturabilir. State selector yalnız relevant field değişimini işleyebilir.

Optimistic UI

Firestore local write'ı client cache'e hızlı yansıtarak optimistic UX sağlayabilir. User network roundtrip beklemeden task completed state'ini görebilir. Pending write indicator trusted server confirmation henüz gelmediğini anlatabilir. Rules reject olursa UI rollback veya error feedback vermelidir. Business-critical irreversible operation yalnız optimistic visual ile tamamlanmış kabul edilmemelidir.

Server-Confirmed Data ile Local Data Arasındaki Fark

Local data user action'a anında cevap verir, server-confirmed data backend tarafından kabul edilmiş state'i temsil eder. Offline user uzun süre local changes taşıyabilir. Product UX hangi state'in kesin sonuç sayıldığını açıkça göstermelidir. Payment veya permission change local-only state'e güvenmemelidir. Snapshot metadata bu ayrımı application state modeline taşımak için kullanılabilir.

Realtime Database Listener Türleri

Realtime Database farklı listener türleriyle bütün value veya child-level değişiklikleri takip etmeye imkan verir. value listener belirli path'in tamamını snapshot olarak alırken child added, changed ve removed event'leri liste tipi data'da incremental update için daha uygundur. Query-bounded listener order, range veya limit ile data scope'unu azaltabilir. Root veya çok geniş path listener bandwidth ve render maliyetini artırır. Listener artık kullanılmadığında reference ve event type ile doğru şekilde kaldırılmalıdır.

Value Listener

Value listener path'teki bütün current data'yı snapshot olarak verir ve alt child değişikliklerinde yeniden event üretir. Küçük configuration veya single resource için kullanışlıdır. Büyük listede her küçük değişiklikte full subtree snapshot işlemek pahalı olabilir. Query scope daraltılmalıdır. Component lifecycle sonunda listener kapatılmalıdır.

Child Added

Child Added existing child'lar için başlangıçta ve yeni child eklendiğinde event üretir. Chat message listesi gibi append ağırlıklı yapıda incremental rendering sağlar. Query limit ile son N message dinlenebilir. Duplicate item handling key üzerinden yapılmalıdır. Pagination ile initial child event behavior test edilmelidir.

Child Changed

Child Changed mevcut child value değiştiğinde event üretir. Client local state key üzerinden ilgili item'i update edebilir. Bütün listeyi baştan fetch etmeye gerek kalmaz. Event frequency yüksekse framework render batch edilmelidir. Permission veya query scope değişimi listener lifecycle ile yönetilmelidir.

Child Removed

Child Removed resource query result'tan çıktığında veya silindiğinde event verebilir. UI listeden item'i kaldırabilir. Soft delete kullanılıyorsa query filter change de benzer sonuç üretebilir. Offline state'te local delete optimistic event yaratabilir. Server reject durumunda item geri gelebilir ve UI buna hazırlıklı olmalıdır.

Query-Bounded Listener

Query-bounded listener bütün path'i dinlemek yerine belirli order, start, end veya limit condition'larıyla scope daraltır. Bu bandwidth ve client processing'i azaltır. Rules query behavior ile uyumlu olmalıdır. Index tanımlanması performans açısından gerekli olabilir. Presence veya feed gibi yüksek değişim alanında limit önemli maliyet kontrol aracıdır.

Listener'ı Ne Zaman Kaldırmak Gerekir?

Route kapandığında, component unmount olduğunda, user logout yaptığında veya query context değiştiğinde eski listener kaldırılmalıdır. User organization değiştirirse önce previous tenant listener kapatılmalıdır. Aynı listener'ı her render tekrar eklemek duplicate event oluşturabilir. Subscription reference merkezi tutulabilir. Network profiler active listener sayısını gözlemlemeye yardımcı olur.

Presence Sistemi Nasıl Kurulur?

Firebase Realtime Database presence sistemi connection state, onDisconnect operation ve server timestamp kombinasyonuyla güvenilir biçimde kurulabilir. Client /.info/connected path'ini izler ve bağlantı sağlandığında kendisine ait connection child oluşturur. Önemli sıra, connection online olarak yazılmadan önce onDisconnect() cleanup operasyonunun server'a kaydedilmesidir. Multi-device kullanıcı için her browser tab veya cihaz ayrı connection child taşıyabilir. Son active connection silindiğinde user offline kabul edilir ve last seen server timestamp güncellenebilir. :contentReference[oaicite:32]{index=32}

Online / Offline

Online state yalnız client'ın browser API'sindeki network bilgisinden değil Firebase server connection state'inden türetilmelidir. /.info/connected Realtime Database bağlantısının gerçekten kurulup kurulmadığını bildirir. User birkaç cihazda online olabilir. Tek boolean yerine connection listesi daha doğru modeldir. UI online badge için aggregate state hesaplayabilir.

/.info/connected

/.info/connected özel path user'ın Realtime Database backend'e bağlantı durumunu client tarafında gösterir. Bu value yalnız ilgili client bağlantısını temsil eder. True olduğunda onDisconnect cleanup önce register edilir. Daha sonra active connection child set edilir. Reconnect durumunda aynı akış tekrar uygulanmalıdır. :contentReference[oaicite:33]{index=33}

onDisconnect()

onDisconnect() server tarafında connection koptuğunda çalıştırılacak operation'ı önceden kaydeder. Connection child remove ve last seen timestamp update buna örnektir. Operation client process kapanmış olsa bile backend disconnect algıladığında uygulanabilir. Firebase örneği race condition riskini azaltmak için disconnect operation'ın online write'tan önce kaydedilmesini önerir. Security Rules onDisconnect tarafından yapılacak write'a da izin vermelidir. :contentReference[oaicite:34]{index=34}

Last Seen

Last Seen user'ın son bağlantı kesilme zamanını gösterir. Client clock yerine server timestamp kullanılmalıdır. Multi-device user'da her connection kapanınca timestamp update etmek “son cihaz kapanması” semantics'ini dikkatle ele almayı gerektirir. Aggregate presence logic connection listesi üzerinden yapılabilir. Privacy requirement user'ın last seen bilgisini kapatmasına izin verebilir.

Server Timestamp

Server timestamp client device clock farklarından bağımsız zaman sağlar. Disconnect operation içinde server timestamp placeholder kullanılabilir. UI local timezone'a formatlayabilir. Rules timestamp structure'ını doğrulayabilir. Audit-sensitive event için backend-generated timestamp tercih edilmelidir.

Multi-Device Presence

User phone, laptop ve iki browser tab'da aynı anda bağlı olabilir. Tek online: true flag her bağlantı kapanınca yanlış offline sonucu üretir. Her connection unique child olarak tutulursa herhangi bir child varken user online kabul edilir. onDisconnect yalnız kendi connection child'ını kaldırır. Bu pattern Firebase presence örneğinde de kullanılır. :contentReference[oaicite:35]{index=35}

Ghost Session Problemi

Ghost session client kapanmasına rağmen user online görünmeye devam ettiğinde oluşur. Client-side unload event'e güvenmek yeterli değildir, çünkü network veya process ani biçimde kesilebilir. onDisconnect server-side cleanup bu riski azaltır. Connection child için timeout veya stale cleanup job ek koruma sağlayabilir. Monitoring uzun süre active görünen şüpheli connection kayıtlarını inceleyebilir.

Realtime Database ve Firestore Offline Davranışı

Firebase database SDK'ları network kesintisinde kullanıcı deneyimini devam ettirmek için local cache ve queued write davranışları sunabilir. Firestore offline persistence platforma göre farklı default'lara sahipken Realtime Database mobil SDK'larında persistence ve local event pattern'leri kullanılabilir. Local write kullanıcıya hemen yansıyabilir ve connection geldiğinde backend ile senkronize edilir. Conflict çözümü service semantics'e göre gerçekleşir ve aynı document'ta Firestore last write wins davranışı gösterebilir. Offline-first tasarımda kullanıcıya local, pending ve server-confirmed state ayrımını anlatmak önemlidir. :contentReference[oaicite:36]{index=36}

Local Cache

Local cache son kullanılan data'yı network olmadan gösterebilir. Firestore web persistent cache explicit olarak açılmadıkça memory cache default davranış olabilir. Mobil SDK'larda persistence default'u farklıdır. Cache user logout sonrasında güvenlik açısından değerlendirilmelidir. Shared cihazda hassas data uzun süre disk üzerinde kalmamalıdır.

Latency Compensation

Latency compensation write server'a ulaşmadan local UI'ın yeni state'i göstermesini sağlar. User interaction hızlı hissedilir. Pending state metadata ile belirtilmelidir. Server Rules write'ı reddederse SDK state'i reconcile eder. Product UX failure durumunda kullanıcıya net feedback vermelidir.

Offline Writes

Offline write local queue içinde tutulabilir ve connection geri geldiğinde backend'e gönderilebilir. User uzun süre offline kalırsa birden fazla değişiklik birikebilir. Security Rules reconnect sırasında write'ları değerlendirmeye devam eder. Permission arada değişmişse bazı write'lar reject olabilir. UI conflict veya denied change durumunu kullanıcıya açıklamalıdır.

Reconnection

Network geri geldiğinde SDK pending data'yı synchronize eder ve server state'i alır. Listener yeni snapshot veya event üretebilir. User online olduktan hemen sonra “her şey kaydedildi” demeden pending state kontrol edilmelidir. Presence reconnect logic de yeniden onDisconnect kaydı oluşturmalıdır. Rapid network switching gerçek cihaz testinde denenmelidir.

Conflict Resolution

Offline iki client aynı resource'u değiştirirse conflict davranışı data modeline göre tasarlanmalıdır. Firestore aynı document write'larında last write wins sonucu görülebilir. Increment operation, transaction veya server-side conflict logic bazı senaryolarda daha uygun olabilir. Collaborative editing için CRDT benzeri özel model gerekebilir. User'ın değişikliğinin üzerine yazıldığını fark etmesi gereken business ekranlarında version field kullanılabilir.

Web ve Mobil Davranış Farkları

Firestore web persistent cache varsayılan olarak kapalıdır, Android ve Apple platformlarında offline persistence varsayılan olarak açıktır. Web persistent cache browser desteği ve shared-device riski nedeniyle explicit kullanıcı kararı gerektirebilir. Realtime Database persistence API'leri de platforma göre farklı davranabilir. “Firebase offline destekliyor” şeklinde tek genel cümle yerine target platform test edilmelidir. Browser private mode ve storage quota behavior ayrıca kontrol edilmelidir. :contentReference[oaicite:37]{index=37}

Firestore Offline Persistence Güvenliği

Firestore web persistent cache performans ve offline UX açısından yararlı olsa da hassas verinin browser storage içinde session sonrasında kalabilmesi güvenlik açısından değerlendirilmelidir. Firebase güncel dokümantasyonu web persistence cache'in oturumlar arasında otomatik temizlenmediğini ve sensitive application'larda user'a trusted device olup olmadığını sormayı öneriyor. Public kiosk veya ortak bilgisayarda persistence açmak risk oluşturabilir. Logout yalnız auth session'ı kapatır, local cache temizliği ayrı strateji gerektirebilir. Veri minimization ve cache policy KVKK değerlendirmesine de dahil edilmelidir. :contentReference[oaicite:38]{index=38}

Web'de Persistent Cache

Web Firestore'da memory cache default seçenek olabilir ve persistent cache explicit config ile etkinleştirilir. Persistent cache browser session'ları arasında data saklayabilir. Offline query ve listener cache üzerinden çalışabilir. Multi-tab manager seçeneği kullanılabilir. Sensitive app default olarak persistence kapalı tutmayı değerlendirebilir.

Shared Device Riski

Ortak bilgisayarda farklı user'lar aynı browser profile'ını kullanabilir. Önceki user'ın local cache data'sı disk üzerinde kalabilir. UI authentication ayrı olsa da forensic veya uygulama bug riski düşünülmelidir. Trusted device confirmation persistence enable kararıyla ilişkilendirilebilir. Kiosk environment memory-only cache tercih edebilir.

Hassas Verilerin IndexedDB'de Kalması

Web persistent cache implementation browser local storage mekanizmalarını kullanır ve hassas document'lar cihaz diskinde kalabilir. Sağlık, finans veya private internal data işleyen uygulamalar data classification yapmalıdır. Sensitive field ayrı document'ta tutulup client cache erişimi azaltılabilir. Server-only data browser'a hiç gönderilmemelidir. Logout sonrası cleanup capability ve product requirement birlikte incelenmelidir.

Trusted Device Yaklaşımı

User “bu cihaz bana ait” seçeneğiyle persistent cache'e izin verebilir. Public computer seçeneğinde memory cache kullanılır. Bu tercih user profile yerine device-local setting olarak tutulabilir. UI açıklaması teknik jargon yerine verinin cihazda saklanabileceğini anlatmalıdır. Security policy enterprise requirement ile uyumlu olmalıdır.

Logout Sonrası Cache Stratejisi

Logout sonrasında in-memory store ve active listener kesinlikle temizlenmelidir. Persistent cache'in silinmesi gerekiyorsa SDK lifecycle ve browser support'a uygun yöntem kullanılmalıdır. Her logout'ta database instance yeniden initialize etmek gerekebilir. Cached data başka user'a UI üzerinden gösterilmemelidir. Automated test same browser session içinde User A logout ve User B login senaryosunu kapsamalıdır.

Optimistic UI ve Firebase

Optimistic UI kullanıcı action'ını server roundtrip beklemeden local olarak göstererek uygulamayı daha hızlı hissettirebilir. Firestore veya Realtime Database local event davranışı bu yaklaşımı doğal biçimde destekler. Ancak local state ile server-confirmed state karıştırılırsa kullanıcı write'ın gerçekten kaydedildiğini sanabilir. Pending write indicator ve failure feedback özellikle offline durumda önemlidir. Security Rules reject veya network conflict durumunda UI rollback davranışı önceden tasarlanmalıdır.

Server'a Gitmeden Local Event

User checkbox işaretlediğinde local SDK state'i hemen güncelleyebilir. UI action'ın karşılığını network gecikmesi olmadan görür. Listener local snapshot üretebilir. Background sync server'a write gönderir. Critical irreversible işlemlerde local event final confirmation sayılmamalıdır.

Pending Write

Pending write backend confirmation bekleyen local değişikliktir. Firestore snapshot metadata hasPendingWrites üzerinden bu state'i gösterebilir. UI küçük sync icon veya “kaydediliyor” status sunabilir. Offline uzun süre devam ederse kullanıcı işin henüz server'a gitmediğini bilmelidir. Server confirmation sonrası indicator kaldırılır.

Başarısız Write

Security Rules veya network-related kalıcı error write'ın başarısız olmasına neden olabilir. UI silent failure yapmamalıdır. Local optimistic state rollback veya error marker ile düzeltilmelidir. User tekrar deneyebilir veya permission change açıklaması alabilir. Error observability permission-denied oranını izlemelidir.

Kullanıcıya Senkronizasyon Durumu Gösterme

Offline-first uygulama “offline”, “bekleyen değişiklik”, “senkronize edildi” gibi state'leri anlaşılır biçimde gösterebilir. Her küçük write için toast göstermek kullanıcıyı yormamalıdır. Toolbar veya item-level subtle indicator yeterli olabilir. Critical data için confirmation daha açık olmalıdır. Metadata ve network state bu UI modelini besler.

Offline-First UX

Offline-first UX network'i normal koşul kabul etmeyip local action'ın anlamlı şekilde devam etmesini sağlar. Cached read user'a eski data gösterebilir ve freshness belirtilmelidir. Write queue conflict riskine sahiptir. Product hangi action'ların offline yapılabileceğini açıkça tanımlar. Payment veya privileged admin action offline queue'ya bırakılmamalıdır.

Firestore Index Tasarımı

Firestore index sistemi query performansının temelidir ve çoğu single-field index otomatik oluşturulabilir. Filter ile sort veya birden fazla field condition kombinasyonu composite index gerektirebilir. Eksik index durumunda SDK error çoğunlukla gerekli index'i oluşturmak için yönlendirme sağlar. Bununla birlikte her field için gereksiz index tutmak storage ve write overhead oluşturur. Production query inventory hangi index'lerin gerçekten gerekli olduğunu belirlemek için kullanılmalıdır.

Single-Field Index

Single-field index tek field üzerinde query ve order operasyonlarını destekler. Firestore birçok field için default index yönetimi sunar. Büyük string veya query edilmeyen field için index exemption maliyet optimizasyonu sağlayabilir. Index değişikliği deployment ve query compatibility ile planlanmalıdır. Security Rules authorization field query'de kullanılıyorsa index gereksinimi ayrıca kontrol edilmelidir.

Composite Index

Composite index birden fazla field query condition veya ordering kombinasyonunu destekler. TenantId ve createdAt gibi sık kullanılan filter-sort ikilisi için gerekli olabilir. Her farklı query shape yeni index ihtiyacı doğurabilir. Gereksiz varyasyon index sayısını artırır. Repository query pattern standardization bu büyümeyi kontrol altında tutabilir.

Filter + Sort

User yalnız kendi tasks data'sını ownerId ile filtreleyip createdAt ile sıralıyorsa composite index gerekebilir. Authorization query constraint ve UX sort requirement böylece aynı index tasarımına bağlanır. Query error development ortamında index ihtiyacını gösterir. Production'da runtime index error görülmemelidir. CI smoke test critical query'leri çalıştırabilir.

Index Error'dan Gerekli Index'i Oluşturma

Firestore missing index error genellikle console'a yönlendiren link sağlar. Developer link üzerinden doğru field order ile index oluşturabilir. Index build zaman alabileceği için production release öncesi staging'de hazırlanmalıdır. Auto-created link kör şekilde uygulanmadan query'nin gerçekten gerekli olup olmadığı gözden geçirilmelidir. Index config source control içinde tutulabilir.

Gereksiz Index Maliyeti

Her write ilgili index entry'lerini güncelleyebilir. Query edilmeyen large field için index tutmak storage ve write overhead yaratabilir. Composite index sayısı büyüdükçe yönetim zorlaşır. Usage review unused query pattern'leri temizleyebilir. Cost optimization yalnız listener read sayısına değil index footprint'e de bakmalıdır.

Realtime Database Index Tasarımı

Realtime Database query performansı data path ve .indexOn tanımıyla yakından ilişkilidir. orderByChild() ile sık sorgulanan child field rules içinde index olarak belirtilmelidir. orderByKey() key yapısına göre doğal sıralama sağlar. Index olmadan büyük path üzerinde server daha fazla data işleyebilir ve bandwidth maliyeti artabilir. Query pattern ile security path yapısını aynı anda planlamak en iyi sonucu verir.

.indexOn

.indexOn Realtime Database Rules içinde hangi child field'ın query index'i olarak tutulacağını belirtir. Query edilen field sayısı sınırlı tutulmalıdır. Sırf ileride gerekebilir düşüncesiyle her alanı indexlemek gereksizdir. Index deployment rules dosyasıyla birlikte version control edilir. Performance profiler query latency ve downloaded data trendini gösterir.

orderByKey

orderByKey() child key sırasına göre query çalıştırır. Push ID kullanılan listelerde chronological benzeri ordering için kullanılabilir. Key design business semantics'e aşırı bağlanmamalıdır. Range ve limit query'leriyle result scope daraltılabilir. Rules query path read iznini ayrıca kontrol eder.

orderByChild

orderByChild() belirli child property değerine göre result ordering ve filtering sağlar. User-owned data için ownerUid field üzerinden query yapılabilir. Büyük dataset'te .indexOn kullanılması önemlidir. Data denormalization query field'ı root child içinde tutmayı gerektirebilir. Client broad path read yerine query-bounded listener kullanmalıdır.

Query Performance

Query performansı result set size, index, path depth ve bandwidth ile birlikte değerlendirilmelidir. Root'tan filter yapmak yerine ilgili domain path seçilmelidir. Limit kullanımı feed veya presence listesinde önemlidir. Monitoring downloaded bytes user başına maliyeti gösterebilir. Emulator functional behavior'ı test ederken production profiler gerçek trafik insight'ı sağlar.

Index ile Bandwidth Arasındaki İlişki

Doğru index server'ın query'yi daha verimli değerlendirmesine yardımcı olabilir ve istemciye gereksiz data transferini azaltabilir. Ancak index tek başına broad listener'ı ucuz hale getirmez. Query result hâlâ çok büyükse bandwidth artar. Path ve limit tasarımı birlikte gerekir. Cost monitoring release sonrası query pattern değişikliklerini yakalamalıdır.

Realtime Listener Performansı Nasıl Optimize Edilir?

Realtime listener optimizasyonunun temel prensibi kullanıcının gerçekten ihtiyaç duyduğu minimum data scope'unu dinlemektir. Root veya geniş collection listener yerine dar path, filtered query ve limit kullanılmalıdır. Bir ekran için tek seferlik read yeterliyse sürekli listener açmak gereksiz maliyet yaratabilir. Component lifecycle kapanınca subscription kapatılmalı ve auth user değişikliğinde eski listener kaldırılmalıdır. Production'da active listener sayısı, bandwidth ve document read trendleri feature bazında izlenmelidir.

Root'u Dinlememek

Realtime Database root listener bütün database tree değişikliklerinden etkilenebilir ve büyük data transferi oluşturabilir. Firestore'da tüm collection listener da benzer şekilde gereksiz geniş olabilir. UI yalnız messages listesine ihtiyaç duyuyorsa ilgili room message path veya query dinlenmelidir. Root admin dashboard gibi özel durumda bile pagination veya aggregate data daha uygun olabilir. Listener scope security boundary ile aynı olmalıdır.

Dar Path Kullanmak

Dar path yalnız ilgili user, room veya project data'sını kapsar. Değişiklik başka domain'de olsa listener etkilenmez. Security Rules daha açık hale gelir. Data model bu path access pattern'i desteklemelidir. Çok fazla duplicate path oluşturmak yerine query ve denormalization dengesi kurulmalıdır.

Query Limitleri

Chat uygulamasında son 50 message dinlemek bütün message geçmişini realtime almak yerine daha doğru olabilir. Pagination ile eski messages user scroll yaptığında fetch edilir. Firestore listener limit result set change behavior test edilmelidir. Realtime Database order ve limit query index ile desteklenmelidir. Limit maliyet ve render workload'u azaltır.

Gereksiz Listener'ları Kapatmak

Hidden tab, inactive route veya closed modal için listener devam etmemelidir. Ancak data freshness product requirement gerektiriyorsa central store listener bilinçli açık tutulabilir. Subscription ownership belgelenmelidir. Duplicate listener detection development tool ile yapılabilir. Logout bütün user-scoped subscriptions'ı temizlemelidir.

Tek Seferlik Read ile Listener Arasında Karar Vermek

Static configuration veya nadiren değişen detail için one-time read yeterli olabilir. Realtime listener yalnız gerçekten live update değer sağladığında kullanılmalıdır. User page'i 30 saniye açık tutuyor ve data hiç değişmiyorsa sürekli listener düşük ek maliyetle kalabilir ama scale'de toplam bağlantı sayısı büyür. Product freshness SLA karar vermelidir. Polling, one-time read ve listener seçenekleri karşılaştırılmalıdır.

Component Lifecycle

Framework component mount olduğunda listener kurulabilir ve unmount sırasında cleanup yapılır. Dependency değişiminde eski listener önce kapatılır. React strict development mode duplicate effect davranışı test edilmelidir. Flutter StreamBuilder subscription ownership anlaşılmalıdır. Centralized cache layer aynı data için birçok component'in ayrı listener açmasını önleyebilir.

Firebase Realtime Sistemlerinde Ölçekleme

Firebase realtime sistemlerinde ölçekleme yalnız database kapasitesini değil concurrent connections, active listener sayısı, bandwidth, write throughput ve data hotspot behavior'ını birlikte değerlendirmeyi gerektirir. Managed service birçok altyapı işini otomatik yönetebilir, ancak kötü query veya gereksiz broad listener yine maliyet ve latency üretir. Realtime Database büyüdüğünde sharding veya birden fazla database instance değerlendirilebilir. Firestore tarafında document write hotspot ve listener fan-out ayrıca izlenmelidir. Capacity planning gerçek user behavior üzerinden yapılmalıdır.

Concurrent Connections

Concurrent connection user'ın açık client session sayısıyla ilişkilidir. Bir user birden fazla tab veya cihaz açabilir. Realtime Database plan limitleri ve usage metrics güncel resmi pricing veya quota dokümanıyla takip edilmelidir. Presence system connection count'u daha da görünür kılar. Capacity alert büyüme trendini önceden yakalamalıdır.

Active Listeners

Her connection birden fazla listener açabilir. Feature başına listener inventory yapmak scale tahminini kolaylaştırır. User aynı data için duplicate listener açıyorsa subscription consolidation yapılabilir. Hidden route listener kapatılabilir. Listener count tek başına maliyet değil result update frequency ile birlikte değerlendirilmelidir.

Bandwidth

Realtime Database büyük JSON subtree update'leri bandwidth tüketebilir. Firestore document read ve network transferi de data size'dan etkilenir. Asset data database yerine Storage üzerinde tutulmalıdır. Large text veya repeated metadata read cost oluşturabilir. Compression ve denormalization trade-off ölçülmelidir.

Write Throughput

High-frequency counter veya presence update aynı key üzerinde hotspot yaratabilir. Distributed counter veya sharded path pattern gerekebilir. User typing indicator her keystroke database write yapmamalıdır. Throttle veya ephemeral channel kullanılabilir. Product event rate capacity modeline dahil edilmelidir.

Database Sharding

Realtime Database büyük workload'u birden fazla database instance'a bölme imkanı sunabilir. Sharding user, tenant veya region gibi stable key üzerinden yapılabilir. Client hangi shard'a bağlanacağını bilmelidir. Cross-shard query zorlaşır. Bu nedenle scaling gerekmeden erken sharding yapıp unnecessary complexity eklememek önemlidir.

Birden Fazla Realtime Database Instance

Bir project içinde birden fazla Realtime Database instance kullanmak workload isolation veya scale için değerlendirilebilir. Tenant setleri instance'lara dağıtılabilir. Rules ve monitoring her instance için yönetilir. Migration ve rebalance tooling gerekir. Bu model ancak gerçek scale ihtiyacı ortaya çıktığında uygulanmalıdır.

Firestore Gerçek Zamanlı Sorgular Nasıl Ölçeklenir?

Firestore realtime query ölçeklemesinde listener fan-out, result set size, write frequency ve hot document behavior'ı birlikte düşünülmelidir. Tek document çok sık güncellenip binlerce client tarafından dinleniyorsa hem write contention hem fan-out oluşabilir. Query scope tenant, user veya time window ile daraltılmalıdır. Region seçimi kullanıcı konumu ve availability ihtiyacıyla birlikte planlanır. Multi-region daha yüksek availability hedefi sunabilir, ancak latency ve cost trade-off'ları güncel resmi dokümanla doğrulanmalıdır.

Snapshot Listener Fan-Out

Bir document değişikliği çok sayıda aktif listener'a iletilebilir. Popular public feed veya global config gibi resource'larda fan-out yüksek olabilir. Update frequency düşükse kabul edilebilir. High-frequency state ayrı architecture gerektirebilir. RUM ve backend metrics listener pattern'i ölçmelidir.

High Write Traffic

Bir collection'a yüksek write dağıtılabilir, ancak aynı document üzerine yoğun write bottleneck oluşturabilir. Counter, analytics veya telemetry tek hot document'a yazılmamalıdır. Batch veya distributed aggregate kullanılabilir. Realtime UI için gereken minimal state ayrı document'larda tutulabilir. Write rate load test yapılmalıdır.

Hot Documents

Hot document çok sık read veya write yapılan tek resource'dur. Global counter veya presence total buna örnek olabilir. Sharded counter pattern kullanılabilir. UI exact realtime global count gerektirmiyorsa periodic aggregate daha ucuz olabilir. Product requirement technical design'i belirlemelidir.

Query Scope

Query result ne kadar dar olursa listener update ve read davranışı o kadar kontrol edilebilir olur. Tenant ID, status veya time window filter kullanılabilir. Pagination live feed'de dikkatle tasarlanmalıdır. Security Rules aynı query scope'uyla uyumlu olmalıdır. Index requirement release öncesi hazırlanmalıdır.

Region Seçimi

Database region kullanıcıların ve backend servislerinin coğrafi konumuna yakın seçildiğinde latency azalabilir. Data residency ve KVKK değerlendirmesi region kararına dahil edilmelidir. Cloud Functions veya backend farklı region'da olursa network latency ve egress etkisi oluşabilir. Project başında region seçimi sonradan migration maliyeti yaratabileceği için dikkatle yapılmalıdır. Legal ve technical requirement birlikte belgelenmelidir.

Regional vs Multi-Region

Regional deployment belirli bölgede data locality ve potansiyel cost avantajı sağlayabilir. Multi-region daha geniş availability hedefi için tercih edilebilir. Exact SLA ve pricing zamanla değişebileceği için güncel Firebase veya Google Cloud dokümanları release kararında kontrol edilmelidir. User latency profile ve regulatory requirement belirleyicidir. “Multi-region her zaman daha iyi” şeklinde genel kural doğru değildir.

Firebase Realtime Listener Maliyeti Nasıl Kontrol Edilir?

Realtime listener maliyeti query scope, result change frequency, reconnect davranışı, document read sayısı ve bandwidth üzerinden büyüyebilir. Gereksiz geniş query en kolay önlenebilir maliyet kaynağıdır. Listener reconnect olduğunda data tekrar okunabilir ve kullanım modeline göre ek read veya bandwidth oluşabilir. Cost dashboard tek toplam rakam yerine feature ve route bazlı usage insight ile desteklenmelidir. Budget alert beklenmedik artışı erken yakalamalıdır.

Gereksiz Geniş Query

Bütün collection'ı dinlemek yerine user veya tenant filter uygulanmalıdır. Feed son N item ile sınırlandırılabilir. Old data pagination ile one-time read yapılabilir. Query result size test data'da değil production-like dataset'te ölçülmelidir. Security ve cost aynı optimizasyondan faydalanır.

Document Reads

Firestore pricing modelinde document reads önemli maliyet kalemidir. Realtime listener result değiştiğinde ilgili read behavior maliyete yansıyabilir. Exact billing semantics güncel pricing dokümanından doğrulanmalıdır. UI gereksiz re-subscribe yapıyorsa read artabilir. Cache layer ve stable listener subscription kullanışlıdır.

Listener Reconnection

Mobile network switching listener'ın reconnect olmasına neden olabilir. Reconnect sonrasında current result set yeniden synchronize edilebilir. Çok geniş query mobil kullanıcıda hem data hem battery maliyeti üretir. Offline cache tekrar transferi azaltabilir, ancak billing behavior resmi dokümanla takip edilmelidir. Network resilience test edilmelidir.

Query Result Changes

Listener query sonucuna yeni document girer, document değişir veya result'tan çıkarsa client event alır. High-frequency update collection canlı dashboard maliyetini büyütebilir. UI gerçekten her değişikliği anında göstermek zorunda mı sorusu sorulmalıdır. Aggregate veya slower polling bazı ekranlarda yeterli olabilir. Realtime özellik ürün değerine göre seçilmelidir.

Bandwidth

Large document veya Realtime Database subtree sık güncellenirse bandwidth artar. User profile içinde büyük metadata taşımak her listener event'ini büyütebilir. Frequently changing field ayrı document veya path'e ayrılabilir. Binary asset database içinde tutulmamalıdır. Network payload inspection veri modelini optimize etmeye yardımcı olur.

Cost Monitoring

Firebase usage dashboard ve Google Cloud billing araçları cost trendini izlemeye yardımcı olabilir. Budget alert belirli threshold'da ekibi bilgilendirebilir. Release veya campaign öncesi expected traffic model hazırlanmalıdır. Sudden read spike listener bug veya bot abuse gösterebilir. App Check ve Rules abuse riskini azaltmaya yardımcı olur.

Firebase App Check Nedir?

Firebase App Check backend kaynaklarını yetkisiz veya sahte client'lardan gelen abuse isteklerine karşı korumaya yardımcı olan application attestation katmanıdır. User'ın kim olduğunu doğrulayan Authentication'dan farklıdır ve resource permission belirleyen Security Rules'un yerini almaz. App Check token valid olduğunda request beklenen app veya device attestation bağlamından gelmiş kabul edilir. Güncel Firebase dokümantasyonuna göre Cloud Firestore, Realtime Database, Cloud Storage ve callable Cloud Functions gibi servisler destekleniyor, Authentication desteği ise Preview olarak listeleniyor. Enforcement açılmadan önce metrics izlemek güvenli rollout yaklaşımıdır. :contentReference[oaicite:39]{index=39}

App Attestation

App attestation request'in yetkili uygulama build'i veya güvenilir device signal'ıyla ilişkili olduğunu doğrulamaya çalışır. Platforma göre farklı provider kullanılır. Token backend request'e eklenir. Enforcement valid token taşımayan request'i reddedebilir. Attestation strong authorization yerine abuse protection olarak düşünülmelidir.

Authentication'dan Farkı

Authentication “bu user kim?” sorusunu cevaplar. App Check “bu request beklenen application bağlamından mı geliyor?” sorusuna yardımcı olur. Signed-out user da App Check token taşıyabilir. Authenticated attacker valid app içinde yetkisiz resource'a erişmeye çalışabilir. Security Rules bu nedenle ayrı katmandır.

Security Rules'dan Farkı

Security Rules resource access policy uygular. App Check owner, role veya tenant membership değerlendirmez. Valid app token taşıyan User A, User B document'ını yine okuyamamalıdır. Rules UID veya membership üzerinden bunu deny eder. İki katman birlikte kullanıldığında abuse ve authorization riskleri ayrı ele alınır.

Abuse Protection

Public Firebase config değerleri internetten görülebilir ve attacker custom script ile project endpoint'lerine trafik göndermeyi deneyebilir. App Check bu custom client request'lerinin geçerli attestation token olmadan backend service'e ulaşmasını zorlaştırır. Rate limiting ve quota monitoring yine önemlidir. High-value backend endpoint ayrıca custom rate limit uygulayabilir. Firebase API key'i gizlemek abuse protection yerine geçmez.

Firestore

Firestore App Check enforcement valid App Check token gerektirebilir. Security Rules aynı request için user authorization'ı ayrıca değerlendirir. Enforcement rollout öncesi metrics içinde valid ve invalid request oranları izlenebilir. Emulator veya local development debug provider gerektirebilir. Production client token renewal behavior test edilmelidir.

Realtime Database

Realtime Database App Check desteklenen servisler arasındadır. Long-lived connection setup App Check token davranışıyla birlikte çalışır. Presence ve realtime data yine Security Rules access policy'sine uyar. Invalid app client connection abuse azaltılabilir. Debug ortamı production attestation provider kullanmamalıdır.

Authentication

Firebase'in Ağustos 2026 App Check genel sayfasında Firebase Authentication desteği Preview olarak gösteriliyor. Bu nedenle production rollout sırasında feature status ve provider documentation güncel olarak kontrol edilmelidir. Authentication user identity sağlamaya devam eder. App Check auth endpoint abuse'ünü azaltmaya yardımcı olabilir. Authorization yine application resource Rules üzerinden uygulanır. :contentReference[oaicite:40]{index=40}

Cloud Functions

Callable Cloud Functions App Check token doğrulamasını kullanabilir. Custom backend için App Check token verify yaklaşımı da uygulanabilir. Function ayrıca Firebase ID token üzerinden user identity doğrulamalıdır. App Check valid olsa bile privileged operation role kontrolü gerektirir. Abuse protection ile authorization ayrı middleware olarak tasarlanabilir.

Web'de Firebase App Check

Web App Check deployment'ında reCAPTCHA Enterprise güncel Firebase tavsiyesi olarak öne çıkıyor. Application console tarafında provider kaydedilir, client SDK App Check token alır ve desteklenen servis request'lerinde token gönderir. Enforcement hemen açılmadan önce metrics izlemek gerçek user request'lerinin valid token taşıyıp taşımadığını gösterir. Local development veya CI ortamlarında production attestation çalışmayabileceği için debug provider kullanılır. Debug token production repository veya public log içinde paylaşılmamalıdır. :contentReference[oaicite:41]{index=41}

reCAPTCHA Enterprise

reCAPTCHA Enterprise web app attestation için Firebase'in yeni integration'larda önerdiği provider'dır. Score-based key kullanıcıya challenge göstermeden signal üretmek için kullanılabilir. Firebase güncel rehberi v3 kullanan projelerin uygun olduğunda Enterprise'a geçmesini güçlü biçimde öneriyor. Provider quota ve pricing ayrıca takip edilmelidir. App Check token user authentication token'ından farklıdır. :contentReference[oaicite:42]{index=42}

App Registration

Firebase console içinde web app App Check provider ile kayıt edilir. Allowed domain ve site key configuration doğru olmalıdır. Development ve production project ayrı registration kullanabilir. Wrong project key token validation failure oluşturabilir. Deployment checklist App Check config environment eşleşmesini doğrulamalıdır.

App Check Token

Client App Check SDK attestation provider'dan signal alıp Firebase App Check token edinir. Token supported Firebase request'lerine eklenir. SDK refresh lifecycle'ı otomatik yönetebilir. Custom backend request'lerinde token ayrıca header ile gönderilip server tarafında verify edilebilir. Token client tarafından trusted authorization data taşımak için kullanılmamalıdır.

Enforcement

Enforcement açıldığında valid App Check token taşımayan request desteklenen servis tarafından reddedilebilir. Bu nedenle mevcut production kullanıcılarının SDK version ve provider config'i hazır olmadan enforcement açmak kesinti yaratabilir. Önce metrics izlenir. Staged rollout planlanır. Incident durumunda enforcement setting ve client error dashboard hızlı erişilebilir olmalıdır.

Enforcement Öncesi Metrics

Firebase App Check metrics valid, invalid veya unverified request dağılımını görmeye yardımcı olur. Enforcement öncesi birkaç release cycle gözlem yapmak legacy client riskini ortaya çıkarabilir. Invalid request bot olabilir veya yanlış config'e sahip gerçek user olabilir. Version segmenti sorunu ayırmaya yardımcı olur. Metrics temizlenmeden enforcement açılmamalıdır.

Debug Provider

Localhost veya CI environment normal attestation provider tarafından valid app sayılmayabilir. Firebase bu senaryolar için debug provider sunar. Debug token yalnız trusted development ortamında kullanılmalıdır. Production build debug provider ile publish edilmemelidir. CI secret store debug token saklamak için kullanılabilir. :contentReference[oaicite:43]{index=43}

Mobil Uygulamalarda App Check

Mobil App Check platformun device ve application attestation sistemleriyle entegre olur. Android tarafında Play Integrity, Apple tarafında App Attest ve DeviceCheck öne çıkan provider'lardır. Debug build ve CI environment production attestation koşullarını karşılamayabileceği için debug provider veya uygun development configuration gerekir. Enforcement açılmadan önce app version dağılımı ve valid token metrics incelenmelidir. Rooted veya modified device policy product requirement'a göre ayrıca değerlendirilmelidir.

Android Play Integrity

Play Integrity Android application ve device integrity signal'larıyla App Check token acquisition'a yardımcı olur. Firebase güncel App Check dokümantasyonu Android provider seçenekleri arasında Play Integrity'yi listeliyor. Play distribution ve debug build behavior ayrıca konfigüre edilmelidir. Quota limitleri production traffic modeline göre izlenmelidir. Valid App Check token user authorization yerine geçmez. :contentReference[oaicite:44]{index=44}

Apple App Attest

App Attest Apple platformlarında application integrity signal sağlayan güçlü provider seçeneklerinden biridir. Device capability ve OS version support planı gerekir. Unsupported cihazlar için fallback strategy dokümantasyona göre belirlenebilir. Production metrics invalid attestation oranını izlemelidir. Authentication ve Security Rules yine ayrı güvenlik katmanları olarak çalışır.

DeviceCheck

DeviceCheck Apple cihazları için App Check provider seçeneklerinden biridir. App Attest destek veya rollout gereksinimine göre değerlendirilebilir. Provider choice uygulama risk profili ve minimum OS desteğiyle birlikte yapılmalıdır. Token refresh network failure senaryosu test edilmelidir. Debug environment production provider'dan ayrılmalıdır.

Debug Build'ler

Debug build development bilgisayarında veya emulator üzerinde normal attestation sağlayamayabilir. App Check debug provider bu environment için kullanılabilir. Debug token development team dışında paylaşılmamalıdır. Release build config test ile karışmamalıdır. CI release job production provider config kullanmalıdır.

CI/CD Ortamları

Automated integration test gerçek attestation provider akışını her zaman çalıştıramayabilir. Debug provider token CI secret olarak saklanabilir. Firebase project development veya staging environment'a ayrılmalıdır. Production data test suite tarafından erişilmemelidir. App Check enforcement testleri staging üzerinde ayrıca çalıştırılabilir.

Firebase Admin SDK Nedir?

Firebase Admin SDK trusted backend ortamlarında user management, token verification, custom claims ve privileged database operation gibi görevleri gerçekleştirmek için kullanılan server SDK'dır. Client SDK'dan temel farkı geniş server yetkileriyle çalışmasıdır. Firestore server libraries Security Rules'u bypass eder ve IAM üzerinden authenticate olur, bu nedenle Admin SDK request'lerinde authorization uygulama backend'inin sorumluluğudur. Service account veya managed cloud credential client bundle'a asla konmamalıdır. Admin SDK yalnız Cloud Functions, Cloud Run, güvenilir server veya secured development script gibi ortamlarda kullanılmalıdır. :contentReference[oaicite:45]{index=45}

Privileged Backend Environment

Privileged environment credential'ın kullanıcı tarafından görülmediği ve deployment access'inin kontrol edildiği server ortamıdır. Cloud Functions veya Cloud Run managed identity kullanabilir. Private server service account credential ile çalışabilir. Developer laptop'ta key file gerekiyorsa secret management ve rotation uygulanmalıdır. Client application privileged environment değildir.

User Management

Admin SDK user create, update, disable, delete ve lookup gibi authentication yönetim operasyonları sunar. Bu action'lar admin dashboard backend'i üzerinden yapılabilir. Request yapan admin'in ID token ve role'ü önce doğrulanmalıdır. Target user validation ve audit log önemlidir. Client'a doğrudan Admin SDK capability verilmemelidir.

Custom Claims

Admin SDK setCustomUserClaims ile access-control claim tanımlayabilir. Existing claim overwrite behavior dikkate alınmalıdır. Claim assignment privileged action olduğu için endpoint authorization güçlü olmalıdır. New claim user'ın ID token refresh sonrasında görünür. Claim payload profile data için kullanılmamalıdır.

Token Verification

Backend client'tan aldığı Firebase ID token'ı Admin SDK ile verify edebilir. Successful verification UID ve claim bilgilerini trusted biçimde sağlar. Authorization header formatı standardize edilmelidir. Expired veya malformed token 401 benzeri response alabilir. Privileged endpoint gerektiğinde revoked token kontrolü de yapabilir.

Database Operations

Admin SDK Firestore veya Realtime Database üzerinde privileged read ve write yapabilir. Firestore server request'leri Security Rules'dan geçmediği için backend hangi resource'a erişileceğini kendisi sınırlandırmalıdır. “Admin SDK kullanıyorum, Rules koruyor” varsayımı tehlikelidir. IAM role minimum required permission ile verilmelidir. Business authorization service layer içinde uygulanabilir.

Admin SDK Neden Client'a Konmamalıdır?

Admin SDK credential client içinde bulunduğunda user geniş backend yetkilerini ele geçirebilir. Mobile binary veya JavaScript bundle secret saklamak için güvenli ortam değildir. Service account key çıkarılabilir ve başka ortamdan kullanılabilir. Bu durum bütün Security Rules modelini bypass edebilir. Client yalnız Firebase client SDK ve user-scoped token kullanmalıdır.

Admin SDK ve Security Rules Arasındaki İlişki

Client SDK request'leri Security Rules üzerinden authorization kontrolü alırken Firestore server client libraries ve Admin SDK trusted server context'inde IAM credential ile çalışır. Firebase resmi dokümantasyonu server client libraries'in Cloud Firestore Security Rules'u bypass ettiğini açıkça belirtir. Bu nedenle backend endpoint gelen user token'ı verify edip kendi authorization check'ini yapmadan Admin SDK ile arbitrary document okumamalıdır. Google IAM service account'ın Firestore'a ne yapabileceğini sınırlar, ancak end-user business permission modelini tek başına bilmez. Application authorization bu iki katman arasında ayrıca uygulanmalıdır. :contentReference[oaicite:46]{index=46}

Client SDK Requests

Client SDK request Firebase Authentication token ve App Check token gibi context ile backend service'e gider. Security Rules request path ve data üzerinden access condition'ı evaluate eder. Denied request client permission error alır. Client source code değişse bile server rule aynı kalır. Bu model direct database access'i güvenli hale getiren temel mekanizmadır.

Server SDK Requests

Server SDK trusted Google credential ile Firestore'a erişebilir. End-user Security Rules uygulanmaz. Backend bir user adına işlem yapıyorsa user permission'ını kendisi değerlendirmelidir. IAM yalnız service identity yetkisini kontrol eder. API endpoint input'u doğrudan document path'e çevrilmemelidir.

Firestore Rules Bypass

Rules bypass privileged backend için faydalıdır çünkü admin task veya server processing client restriction'larından bağımsız çalışabilir. Fakat access control responsibility server code'a taşınır. Backend bug bütün tenant data'yı açabilir. Integration test user A'nın tenant B endpoint access'ini reddetmelidir. Security review server repository layer'i de kapsamalıdır.

Google IAM

IAM service account veya workload identity'nin Google Cloud resource üzerinde hangi operation'ı yapabileceğini belirler. Backend service yalnız gerekli role'e sahip olmalıdır. Owner veya Editor gibi geniş project role production service'e gereksiz olabilir. Least-privilege IAM blast radius'i azaltır. IAM end-user resource ownership'in yerine geçmez.

Backend Authorization'ın Ayrıca Uygulanması

Backend önce Firebase ID token verify eder, sonra UID ve claim bilgisine göre operation authorization yapar. Resource tenant ID veya owner ID database'den okunabilir. Authorization success sonrası Admin SDK operation çalışır. Client gönderdiği role parameter trusted değildir. Policy service bütün endpoint'lerde ortak kullanılabilir.

Service Account Güvenliği

Service account key repository, client config veya public CI log içinde bulunmamalıdır. Managed identity mümkünse static key kullanımından daha iyi olabilir. Key leak durumunda revoke ve credential rotation hemen yapılmalıdır. IAM audit log access'i incelemeye yardımcı olur. Deployment environment secret access minimum team ile sınırlandırılmalıdır.

Firebase ID Token Backend'de Nasıl Doğrulanır?

Client sign-in sonrasında Firebase ID token alır ve backend request'ine genellikle Authorization header içinde Bearer token olarak ekler. Backend Admin SDK verifyIdToken() benzeri API ile signature, issuer, audience ve expiry gibi kontrolleri doğrular. Successful result UID ve custom claim bilgilerine erişim sağlar. Security-sensitive endpoint revoked token kontrolü de uygulayabilir. User kimliği request body içindeki UID parametresinden değil verified token sonucundan alınmalıdır. :contentReference[oaicite:47]{index=47}

Client ID Token

Client current authenticated user üzerinden ID token alabilir. Token kısa ömürlüdür ve SDK refresh lifecycle'ını yönetir. Her request için local storage'daki eski token string'ini elle tutmak gereksizdir. HTTPS dışında token gönderilmemelidir. XSS riskine karşı web application security ayrıca önemlidir.

Authorization Header

Backend standard Authorization: Bearer TOKEN formatını kullanabilir. Middleware header'ı parse eder. Token yoksa unauthenticated response döner. Malformed token log'a raw value olarak yazılmamalıdır. Reverse proxy header forwarding config doğrulanmalıdır.

Admin SDK Token Verification

Admin SDK token signature ve Firebase project context'ini doğrular. Verification success kullanıcı identity için trusted base sağlar. Expired token reject edilir. Revocation check optional additional security olabilir. Backend error response internal verification detail'ı dışarı sızdırmamalıdır.

UID

Verified token içindeki UID current user'ın güvenilir identity'sidir. Resource ownership query bu UID üzerinden yapılır. Client body içinde gönderilen userId yalnız target resource identifier olabilir. “Ben şu user'ım” iddiası body'den kabul edilmez. Audit log verified UID kullanmalıdır.

Custom Claims

Verified token custom claim içerebilir. Admin endpoint admin === true veya role value kontrol edebilir. Claim eski olabilir çünkü token refresh lifecycle vardır. Kritik role revoke durumunda refresh token revoke değerlendirilebilir. Tenant-specific membership database'den ayrıca doğrulanabilir.

Token Expiry

Firebase ID token yaklaşık bir saatlik kısa ömre sahiptir. Client SDK refresh token kullanarak yeni ID token alabilir. Backend expired token'ı kabul etmemelidir. Clock skew library tarafından uygun şekilde yönetilir. Long-running connection veya websocket token refresh strategy ayrıca tasarlanmalıdır. :contentReference[oaicite:48]{index=48}

Revoked Token

Admin SDK refresh token revoke edebilir ve verification sırasında revoked status kontrol edilebilir. Suspicious session, lost device veya privilege downgrade durumunda kullanışlıdır. Revocation check ek backend call veya latency trade-off oluşturabilir. High-risk endpoint stricter policy kullanabilir. User revoke sonrası tekrar authentication yapmak zorunda kalabilir. :contentReference[oaicite:49]{index=49}

Privileged İşlemler Nerede Yapılmalıdır?

Privileged operation client tarafından doğrudan gerçekleştirilemeyecek kadar yüksek güven gerektiren işlemdir. Admin role atama, başka kullanıcının verisini değiştirme, payment webhook işleme, sensitive aggregate hesaplama ve secret içeren business logic güvenilir backend ortamında çalıştırılmalıdır. Cloud Functions, Cloud Run veya özel backend bu sorumluluğu üstlenebilir. Backend user ID token'ı verify eder ve authorization kontrolünden sonra Admin SDK veya başka service credential kullanır. Bu işlemleri client'a bırakmak security boundary'yi ortadan kaldırır.

Admin Role Atama

User kendi custom claim'ini set edemez. Admin role assignment yalnız mevcut trusted admin veya deployment process tarafından backend üzerinden yapılmalıdır. Target UID doğrulanır. Audit log actor ve target user kaydeder. Claim update sonrası token refresh gerekir.

Başkasının Verisini Değiştirme

Support veya moderator başka user resource üzerinde işlem yapacaksa backend operation daha güvenli olabilir. Backend actor role ve target resource tenant relationship'i kontrol eder. Admin SDK write gerçekleştirir. Client target document path'i keyfi biçimde değiştirememelidir. Action audit log'a yazılmalıdır.

Payment Webhook

Payment provider webhook secret veya signature verification gerektirir ve client içinde çalıştırılmamalıdır. Backend event authenticity doğrular. Subscription state Firestore'a yazılabilir ve premium custom claim güncellenebilir. Idempotency duplicate webhook'u güvenli hale getirir. Client yalnız server-confirmed subscription state'i görüntüler.

Aggregate Calculation

Büyük dataset aggregate işlemi client'a bütün document'ları indirip hesaplatmamalıdır. Backend scheduled function veya Firestore aggregation query kullanılabilir. Result precomputed document'a yazılabilir. Access sensitive aggregate user permission'ına göre sınırlandırılır. Cost monitoring calculation frequency'yi optimize eder.

Sensitive Business Logic

Fraud rule, discount secret, internal scoring veya privileged workflow client bundle'da bulunmamalıdır. Client code kullanıcı tarafından okunabilir. Backend secret ve logic trusted environment'da kalır. Input validation ve auth check birlikte yapılır. Result minimum gerekli data ile client'a döndürülür.

Cloud Functions / Cloud Run / Özel Backend

Cloud Functions event-driven ve callable işlem için uygun olabilir. Cloud Run container tabanlı uzun-lived service veya özel runtime ihtiyacında esneklik sağlar. Özel backend mevcut infrastructure ile Firebase Authentication'ı birleştirebilir. Seçim latency, scaling, language ve deployment gereksinimine göre yapılır. Hepsinde ortak kural privileged credential'ın client'ta bulunmamasıdır.

Firebase Security Rules Nasıl Test Edilir?

Security Rules testleri UI testinden bağımsız olarak farklı authentication context ve payload'larla authorization boundary'yi doğrulamalıdır. Firebase Emulator Suite production data'ya dokunmadan Firestore veya Realtime Database Rules üzerinde otomatik test çalıştırmayı sağlar. Guest, authenticated user, owner, different user, admin ve invalid data senaryoları minimum test setidir. Her allow case kadar deny case de önemlidir. Rule change pull request'te bu testlerden geçmeden production'a çıkmamalıdır.

Rules Simulator

Firebase console Rules Simulator belirli path ve auth context için manuel request denemeye yardımcı olabilir. Hızlı debug için kullanışlıdır. Ancak bütün permission matrix'i manuel simulator'a bırakmak regression güvenliği sağlamaz. Emulator automated test ile tamamlanmalıdır. Production issue sırasında belirli rule condition'ı hızlı doğrulamak için kullanılabilir.

Firebase Emulator Suite

Emulator Suite local Firestore, Realtime Database, Authentication ve Functions gibi servislerle integration test kurmayı sağlar. Test user token context simüle edilebilir. Rules source repository'den yüklenir. CI pipeline emulators çalıştırıp allow ve deny assertions yapabilir. Production project data'sına ihtiyaç duyulmaz.

Authenticated User Test

Signed-in normal user hangi public veya member resource'ları okuyabiliyor test edilir. Authentication presence tek başına broad access vermemelidir. Create ve update expected field'larla başarılı olabilir. Admin-only operation deny olmalıdır. Test user claim minimum tutulur.

Unauthenticated User Test

Guest request private resource read ve write yapamamalıdır. Public content varsa yalnız intended path read açık olmalıdır. Anonymous authentication ile unauthenticated state karıştırılmamalıdır. Auth null condition explicit test edilir. Broad wildcard accidental public access bu testte yakalanabilir.

Owner Test

Resource owner kendi data'sında allowed operasyonları yapabilmelidir. Owner update protected field'ı değiştirmeye çalıştığında deny almalıdır. Delete permission business policy'ye göre test edilir. Query owner condition taşımalıdır. Owner test yalnız happy path değil invalid payload da içerir.

Different User Test

User B, User A resource ID'sini direct get ile okumaya çalışır ve deny beklenir. Update ve delete aynı şekilde reddedilmelidir. Collection query unauthorized document ihtimali taşıyorsa Firestore request fail olmalıdır. Bu test horizontal privilege escalation riskini yakalar. Multi-tenant projede farklı tenant user testi ayrıca eklenir.

Admin Test

Admin claim taşıyan user expected privileged action'ları yapabilmelidir. Admin claim olmayan user aynı request'te deny almalıdır. Tenant admin global resource'a erişememelidir. Claim refresh simulation gerekebilir. Backend endpoint admin authorization testleri Rules testinden ayrı çalıştırılmalıdır.

Invalid Data Test

Required field eksik, type yanlış veya immutable field değiştirilmiş payload deny olmalıdır. User role: admin gibi privilege field eklemeyi denemelidir. Oversized veya unexpected field schema policy'ye göre reject edilebilir. Realtime Database .validate testleri delete behavior'ı da kapsamalıdır. Negative test security regression için çok değerlidir.

Authorization Test Matrisi Nasıl Oluşturulur?

Authorization test matrisi role ve resource relationship kombinasyonlarını sistematik hale getirir. Guest, user, resource owner, editor, moderator ve admin sütun veya satırlarda tanımlanabilir. Read, create, update ve delete operation'ları için allow ya da deny sonucu açık biçimde yazılır. Matrix product requirement ile Security Rules arasında ortak dil oluşturur. CI testleri bu tablodaki her hücreyi otomatik assertion'a dönüştürebilir.

Guest

Guest authentication yapmamış kullanıcıdır. Public resource read dışında private data access almamalıdır. Write çoğu uygulamada deny olabilir. Public feedback veya form submission gerekiyorsa abuse protection ve validation ayrıca gerekir. App Check guest authorization yerine geçmez.

User

Normal signed-in user temel member resource'larına erişebilir. Kendi profile ve owned data'sı allowed olabilir. Başka user private resource'u deny olmalıdır. Admin operation deny kalır. User permission product requirement'a göre sınırlandırılır.

Resource Owner

Owner resource üzerindeki daha geniş update veya delete permission'a sahip olabilir. Owner protected tenant veya createdBy field değiştirememelidir. Sharing ayarı ownership'ten ayrı permission modeli gerektirebilir. Ownership transfer privileged backend'e ayrılabilir. Test existing ve incoming document state'ini karşılaştırır.

Editor

Editor belirli project veya tenant resource'larında update yapabilir. User management yetkisi olmayabilir. Delete permission ayrı karar olabilir. Cross-tenant edit kesinlikle deny olmalıdır. Membership revoked edildiğinde yeni request erişim kaybetmelidir.

Moderator

Moderator report veya content status gibi belirli alanları değiştirebilir. Whole document unrestricted update vermek gereksiz risk oluşturabilir. Field-level write condition kullanılabilir. Sensitive private data read permission ayrıca sınırlandırılır. Audit log moderator operation'ları izler.

Admin

Admin geniş application permission'ına sahip olabilir. Ancak production system owner veya infrastructure operation ayrı role gerektirebilir. Admin action MFA ve audit policy ile korunabilir. Custom claim assignment yalnız trusted backend üzerinden yapılır. Rule matrix admin bypass condition'larını açıkça gösterir.

Read/Create/Update/Delete İçin Beklenen Sonuçlar

Her role-resource kombinasyonunda dört temel operation sonucu yazılmalıdır. Update için protected field mutation gibi alt senaryolar eklenir. Query list ile single document get ayrı test edilebilir. Delete soft-delete veya hard-delete policy'ye göre ayrıştırılır. Matrix değişmeden Rules değişiyorsa review sırasında gerekçe sorulmalıdır.

Firebase Rules CI/CD Pipeline'a Nasıl Eklenir?

Rules CI/CD entegrasyonu security policy değişikliklerini normal application code kalitesinde yönetmeyi sağlar. Rules dosyası Git repository içinde tutulur ve pull request üzerinde diff görülebilir. Emulator tests allow ve deny case'lerini otomatik çalıştırır. Staging project'e deploy sonrası integration test yapılır ve approval ile production deployment gerçekleşir. Rule version ve rollback source control commit üzerinden izlenebilir.

Rules Dosyasını Git'te Tutmak

Firestore veya Realtime Database rules file repository içinde application code ile birlikte versionlanmalıdır. Console manual change yapılırsa source of truth bozulur. Team review broad allow veya wildcard değişikliğini görebilir. Commit message permission change nedenini açıklamalıdır. Protected branch security review zorunlu tutabilir.

Emulator Tests

CI local emulator başlatıp rules test suite çalıştırabilir. Guest, owner, different user ve admin contexts oluşturulur. Database seed test fixture ile hazırlanır. Network'e production credential gerekmez. Test failure deployment'ı durdurur.

Pull Request Security Testleri

Rule diff automatic security test'i tetiklemelidir. Broad allow pattern static check ile işaretlenebilir. Permission matrix regression tests çalışır. Reviewer expected policy change ile code diff'i karşılaştırır. Security-sensitive collection için ikinci approval gerekebilir.

Staging Deployment

Rules önce staging Firebase project'e deploy edilir. Frontend staging build gerçek SDK ile integration test yapar. App Check ve authentication provider staging config'i ayrı tutulur. Production data kullanılmaz. Permission denied error dashboard incelenir.

Production Deployment

Production deployment yalnız successful tests ve approval sonrası yapılmalıdır. Firebase CLI target project ID doğrulanmalıdır. Accidental dev-to-prod rule deploy guard eklenebilir. Release note permission behavior değişikliğini belirtir. Monitoring deployment sonrası error spike izler.

Rule Versioning

Git commit rule version geçmişini sağlar. Breaking permission change application deployment ile koordineli olmalıdır. Client eski version yeni Rules altında çalışamıyorsa staged rollout gerekir. Rule comment business policy gerekçesini açıklayabilir. Changelog audit için yararlıdır.

Rollback

New Rules unexpected permission denial yaratırsa önceki safe commit hızlıca deploy edilebilir. Rollback broad insecure rule'a dönüşmemelidir. Incident sırasında hangi user flow'un etkilendiği izlenir. Production logs sensitive data içermeden permission error context'i sunabilir. Post-incident test coverage artırılır.

Firebase Güvenlik Anti-Pattern'leri

Firebase güvenlik hatalarının çoğu platformun direct-client access modelini klasik frontend authorization gibi ele almaktan kaynaklanır. Test mode'u production'da bırakmak, authenticated bütün user'lara bütün data'yı açmak ve client role kontrolünü güvenlik sanmak başlıca örneklerdir. Admin SDK'nın Rules'u bypass etmesi unutulursa güvenli görünen backend endpoint başka tenant verisini açabilir. Service account key repository veya client içine konmamalıdır. Security Rules test edilmediğinde küçük bir path değişikliği beklenmedik data leak'e dönüşebilir.

Production'da Test Mode Bırakmak

Test mode hızlı development için geniş access sağlayabilir. Production trafik başlamadan önce Rules minimum permission modeline geçirilmelidir. Console warning göz ardı edilmemelidir. CI broad allow pattern'i fail edebilir. Staging'de production-like Rules kullanılması migration riskini azaltır.

allow read, write: if true

Firestore'da unconditional allow bütün matching resource'ları public yapabilir. Bu rule yalnız local demo için bile dikkatle kullanılmalıdır. Production default deny olmalıdır. Public read gerekiyorsa yalnız belirli collection veya field visibility pattern'iyle scope daraltılmalıdır. Public write çoğu durumda abuse protection ve validation gerektirir.

Bütün Authenticated Kullanıcılara Bütün Veriyi Açmak

request.auth != null bütün user'ları aynı permission seviyesine getirir. Private profile, organization data veya billing document bu şekilde korunamaz. Ownership veya membership condition eklenmelidir. Authenticated attacker gerçek account açarak data'yı okuyabilir. App Check bunu authorization açısından çözmez.

Frontend Role Kontrolünü Güvenlik Sanmak

UI admin button'ını gizlemek kullanıcı deneyimidir. User network request'i doğrudan gönderebilir. JavaScript role variable değiştirilebilir. Rules signed token claim veya trusted membership kontrol etmelidir. Backend endpoint aynı policy'yi tekrar uygular.

Security Rules'u Filtre Sanmak

Firestore broad query yapıp Rules'un unauthorized document'ları ayıklamasını beklemek yanlıştır. Query all-or-nothing değerlendirilir. Rules condition ile query constraint uyumlu olmalıdır. Realtime Database parent path read de child rules'a göre filtrelenmez. Data model authorization path'ine göre tasarlanmalıdır. :contentReference[oaicite:50]{index=50}

Broad Wildcard Rule Kullanmak

Recursive wildcard üzerinde geniş allow birçok collection'ı farkında olmadan açabilir. Yeni collection eklendiğinde eski broad rule otomatik etkileyebilir. Explicit path permission daha güvenlidir. Shared helper function condition ile birlikte kullanılabilir. Test yeni resource'un default deny kaldığını doğrulamalıdır.

Admin SDK'yı Client'a Koymak

Admin SDK server credential gerektirir ve client environment trusted değildir. Credential extraction bütün project resource'larını tehlikeye atabilir. Client yalnız user-scoped SDK kullanmalıdır. Privileged operation backend API üzerinden yapılmalıdır. Key leak durumunda credential hemen revoke edilmelidir.

Service Account Key'i Repository'ye Eklemek

Git history'den silmek yalnız working tree'den silmekten farklıdır. Key repository'ye commit edildiği anda compromised kabul edilmelidir. Credential revoke ve rotate edilmelidir. Secret scanning pipeline kullanılabilir. Managed workload identity static key ihtiyacını azaltabilir.

Rules Testi Yazmamak

Rules syntax doğru compile olsa bile business authorization yanlış olabilir. Different-user veya cross-tenant access ancak testle görünür. Emulator test CI'da hızlı çalışabilir. Allow ve deny assertions birlikte yazılmalıdır. Permission matrix değiştikçe tests güncellenmelidir.

Authentication Güvenlik İyileştirmeleri

Authentication security yalnız kullanıcıya login formu göstermekten ibaret değildir. Email verification, MFA, disabled account, refresh token revocation, anonymous account linking ve account recovery birlikte değerlendirilmelidir. High-risk admin veya finance account daha güçlü policy gerektirebilir. Session theft veya lost device durumunda revocation mekanizması önemlidir. User recovery flow güvenli değilse güçlü login mekanizması kolayca etkisiz hale gelebilir.

Email Verification

Email-password signup sonrasında email ownership doğrulanabilir. Domain-based access rule yalnız email suffix değil email_verified signal'ını da dikkate almalıdır. Firebase insecure rules rehberi email domain access için verified email kontrolünün önemini açık biçimde gösterir. Verification email resend abuse rate limit gerektirebilir. Critical resource user verification tamamlanana kadar kapalı tutulabilir. :contentReference[oaicite:51]{index=51}

MFA

Multi-factor authentication password veya federated login compromise durumunda ek güvenlik katmanı sağlar. Admin ve privileged user'larda MFA daha güçlü requirement olabilir. Recovery code veya second-factor loss senaryosu destek süreciyle planlanmalıdır. UX friction risk seviyesine göre dengelenir. Backend yalnız MFA gerektiren action için recent authentication check uygulayabilir.

Disabled Accounts

Admin user account'ı disable ederek yeni authentication işlemlerini engelleyebilir. Existing token lifecycle nedeniyle revocation veya backend check gerektiğinde uygulanabilir. HR offboarding veya abuse incident bu feature'ı kullanabilir. Disabled user'ın active listener davranışı test edilmelidir. Audit log disable actor ve reason kaydedebilir.

Refresh Token Revocation

Refresh token revoke user session'larını etkisiz hale getirmek için kullanılabilir. Firebase Admin SDK bu capability'yi destekler. Backend high-risk endpoint revoked token kontrolü yapabilir. Password change gibi major account event token lifecycle'ını etkileyebilir. Incident response playbook revocation adımını içermelidir. :contentReference[oaicite:52]{index=52}

Anonymous Account Linking

Anonymous user'ın cart veya onboarding data'sı permanent account oluşturulduğunda provider account'a link edilebilir. Yeni UID oluşturup eski data'yı orphan bırakmamak için linking flow tercih edilebilir. Account collision senaryosu test edilmelidir. Anonymous user privileged data'ya erişmemelidir. Cleanup policy kullanılmayan anonymous accounts için planlanabilir.

Account Recovery

Password reset email account recovery'nin kritik parçasıdır. Recovery email compromise bütün authentication security'yi etkiler. User email değişikliği recent authentication gerektirebilir. Support manual recovery süreci social engineering riskine karşı documented olmalıdır. Recovery event audit ve notification ile izlenebilir.

Firebase ve KVKK

Firebase kullanan projelerde KVKK değerlendirmesi yalnız Firebase'in hangi ülkede servis verdiği sorusuyla sınırlı değildir. Hangi kişisel verinin toplandığı, neden gerekli olduğu, hangi region'da tutulduğu, kimlerin erişebildiği, client offline cache'de kalıp kalmadığı ve ne kadar süre saklandığı belgelenmelidir. Data minimization gereksiz kişisel field'ların hiç toplanmamasını sağlar. Account deletion user'a ait Firestore, Realtime Database, Storage ve log data lifecycle'ını kapsamalıdır. Hukuki yükümlülükler proje ve veri kategorisine göre değişebileceği için teknik tasarım güncel hukuk danışmanlığıyla birlikte değerlendirilmelidir.

Hangi Kişisel Veriler Firebase'e Gönderiliyor?

Authentication email, phone veya provider identifier gibi veriler içerebilir. Database profile, message, event participation veya device-related state taşıyabilir. Analytics veya monitoring ayrı data kategorileri oluşturabilir. Data inventory her Firebase product için tutulmalıdır. Developer convenience için gereksiz field eklenmemelidir.

Data Minimization

Yalnız product function için gerekli kişisel data toplanmalıdır. User profile içinde bütün provider data'yı kopyalamak çoğu zaman gereksizdir. Sensitive field ayrı server-only store'a taşınabilir. Retention süresi data amacıyla uyumlu olmalıdır. Data minimization security breach etkisini de azaltır.

Database Location

Firestore veya Realtime Database location seçimi data residency ve latency açısından önemlidir. Legal requirement hangi bölgelerin uygun olduğunu belirleyebilir. Backend Functions veya Cloud Run location ile database location arasında network path oluşur. Region seçimi project başlangıcında belgelenmelidir. Sonradan migration maliyeti yüksek olabilir.

Access Control

Personal data yalnız gerekli role ve resource owner tarafından erişilebilir olmalıdır. Security Rules default deny ile başlar. Admin access audit edilir. Support staff minimum scope ile çalışır. Backend service account IAM permission'ı da least privilege olmalıdır.

Offline Cache

Firestore web persistent cache hassas data'yı browser storage içinde session sonrasında tutabilir. Shared device policy bu nedenle önemlidir. Trusted device confirmation değerlendirilebilir. Logout sonrası cache strategy belgelenir. Mobile local storage encryption ve device lock behavior ayrıca incelenebilir. :contentReference[oaicite:53]{index=53}

Logging

Log içine ID token, service account key veya tam kişisel payload yazılmamalıdır. Error diagnosis için UID yerine gerektiğinde pseudonymous identifier kullanılabilir. Retention süresi sınırlanmalıdır. Production log access role-based olmalıdır. Security incident audit ihtiyacı ile privacy dengelenmelidir.

Account Deletion

User Firebase Authentication account'ı silindiğinde Firestore veya Storage data otomatik olarak her zaman temizlenmiş sayılmaz. Data deletion workflow bütün bağlı resource'ları bulmalıdır. Server-side cleanup function kullanılabilir. Legal retention gerekiyorsa anonymization veya retention policy uygulanabilir. User'a deletion sonucu açıkça bildirilmelidir.

Data Retention

Message, log, profile ve backup verileri için retention period ayrı tanımlanabilir. Sonsuza kadar data saklamak varsayılan olmamalıdır. Scheduled cleanup function kullanılabilir. Tenant contract farklı retention gerektirebilir. Deletion işlemi backup ve offline cache etkisini de değerlendirmelidir.

React ile Firebase Entegrasyonu

React ile Firebase entegrasyonunda en önemli tasarım kararı SDK instance'larını component render içinde tekrar oluşturmamak ve authentication ile listener lifecycle'ını açık biçimde yönetmektir. Firebase modular SDK tree-shaking açısından modern yaklaşım sunar. Auth Context user identity'yi component tree'ye taşıyabilir, ancak global role state gerçek security boundary değildir. Firestore onSnapshot subscription useEffect içinde kurulup cleanup edilmelidir. Protected route yalnız UX kontrolüdür ve Rules server-side data protection'ı sürdürür.

Firebase Modular SDK

Modular SDK function-based import ile yalnız kullanılan Firebase package parçalarının bundle'a eklenmesini kolaylaştırır. App initialization tek module içinde yapılabilir. Auth, Firestore ve App Check instance'ları export edilebilir. Duplicate app initialization hot reload sırasında engellenmelidir. Bundle analyzer unused Firebase service import'larını gösterebilir.

Auth Context

Auth Context current user, loading ve signOut action gibi state'i React tree boyunca paylaşabilir. Context içine her Firestore document'ı koymak unnecessary rerender oluşturabilir. Role UI state token claim üzerinden tutulabilir. Security Rules gerçek access'i enforce eder. Context provider auth listener cleanup yapmalıdır.

onAuthStateChanged

onAuthStateChanged provider mount olduğunda subscription kurar. Callback user veya null state'i günceller. Initial loading callback gelene kadar true kalır. Cleanup listener provider unmount olduğunda çağrılır. Claim refresh gerektiğinde token result ayrı izlenebilir.

onSnapshot

Component current UID veya tenant ID belli olduktan sonra query oluşturur. onSnapshot data ve error callback ile subscription başlatır. Dependency değiştiğinde eski listener cleanup edilir. Broad collection query yerine authorization-scoped query kullanılır. Snapshot state update list rendering performansına göre normalize edilebilir.

useEffect Cleanup

useEffect return function listener unsubscribe için doğal yerdir. Effect dependency user UID değiştiğinde cleanup çalışır. Strict development behavior duplicate subscription bug'ını görünür hale getirebilir. Subscription reference lost edilmemelidir. Logout global data cache'i de temizlemelidir.

Protected Routes

Protected route auth loading tamamlandıktan sonra user state'e göre navigation yapar. Admin route claim kontrolüyle UI access'i yönetebilir. Ancak direct Firestore request Rules tarafından ayrıca korunur. Server-rendered React framework kullanılıyorsa token verification server boundary'de yapılabilir. Unauthorized redirect sensitive data fetch edilmeden önce gerçekleşmelidir.

Next.js ile Firebase Entegrasyonu

Next.js ile Firebase entegrasyonunda client ve server runtime sınırı doğru ayrılmalıdır. Browser tarafında Firebase Client SDK Authentication ve Firestore direct access için kullanılabilir. Server route handler, server action veya backend utility içinde Admin SDK trusted credential ile çalışabilir. Client ID token server'a gönderildiğinde verify edilmeden UID veya role kabul edilmemelidir. Environment variable kullanırken public prefix taşıyan değerlerin browser bundle'a çıkabileceği unutulmamalıdır.

Client SDK

Client component Firebase Auth veya Firestore Client SDK kullanabilir. Browser config public olabilir. Security Rules client database request'lerini korur. App Check web client'ta initialize edilebilir. Client SDK server bundle içine gereksiz dahil edilmemelidir.

Admin SDK

Admin SDK yalnız server runtime içinde import edilmelidir. Service account veya application default credential client'a sızmamalıdır. Serverless environment'da duplicate initialization kontrol edilir. Firestore Rules bypass behavior nedeniyle endpoint authorization açık olmalıdır. Server component yalnız trusted user context sonrası privileged data okuyabilir.

Client Component

Interactive auth state veya realtime listener browser client component içinde çalışabilir. useEffect listener lifecycle yönetir. User-specific query Security Rules ile korunur. Initial server HTML sensitive user data taşımıyorsa hydration sonrası auth load yapılabilir. UX loading state doğru tasarlanmalıdır.

Server-Side Token Verification

Client request Authorization header ile Firebase ID token gönderebilir. Server Admin SDK token'ı verify eder. UID verified result'tan alınır. Custom claim role check burada yapılabilir. Revocation check high-risk route için değerlendirilebilir.

Environment Variables

Firebase client config environment variable içinde tutulabilir, ancak client'a expose edilen config secret değildir. Service account private key yalnız server environment variable veya secret manager içinde kalmalıdır. Newline formatting private key deployment'da dikkat ister. Managed identity mümkünse static key kullanımı azaltılabilir. Environment dev, staging ve production project'lerini ayırır.

Server Authorization

Server route verified UID aldıktan sonra resource membership kontrol eder. Admin SDK Firestore query çalıştırır. Client path parametresini doğrulamadan privileged data fetch edilmez. Tenant ID token veya database membership ile eşleştirilir. Application policy shared middleware halinde tutulabilir.

Flutter ile Firebase Entegrasyonu

Flutter Firebase entegrasyonunda FlutterFire paketleri Authentication, Firestore, Realtime Database ve App Check servislerini platformlar arasında kullanmayı kolaylaştırır. Stream tabanlı data akışı Flutter widget yapısıyla doğal biçimde entegre olabilir. Bununla birlikte stream subscription lifecycle ve offline persistence behavior her platformda aynı varsayımla ele alınmamalıdır. Security Rules client UI'dan bağımsız server-side enforcement sağlar. Android ve iOS App Check provider'ları release build'lerde doğru environment config ile etkinleştirilmelidir.

FlutterFire

FlutterFire Firebase servislerinin resmi Flutter package ekosistemidir. CLI configuration platform Firebase app registration'larını oluşturmayı kolaylaştırır. Flavor bazlı dev ve prod config kullanılabilir. Package version upgrade release notes ile test edilmelidir. Native build configuration CI pipeline'a dahil edilmelidir.

Firebase Auth

Firebase Auth stream current user state'i widget tree'de sağlayabilir. Loading ve signed-out state ayrı tasarlanır. Token claim gerekiyorsa ID token result alınabilir. Client role güvenlik boundary'si değildir. Logout user-specific stream'leri durdurmalıdır.

Firestore Streams

Firestore snapshot streams query result değişikliklerini Flutter'a iletir. StreamBuilder küçük ekranlar için basit olabilir. Büyük application repository layer stream'i domain modeline çevirebilir. Query tenant veya user scope'lu olmalıdır. Offline snapshot metadata UX'te kullanılabilir.

Realtime Database Streams

Realtime Database value ve child event stream'leri chat veya presence için kullanılabilir. Listener path dar tutulmalıdır. Widget dispose subscription'ı kapatmalıdır. Multi-device presence onDisconnect platform lifecycle'dan bağımsız server behavior sağlar. Network reconnect test edilmelidir.

Security Rules

Flutter form validation Rules'un yerine geçmez. User modified APK ile direct request gönderebilir. Firestore veya Realtime Database server-side rule aynı access'i uygular. Emulator tests Flutter integration testten ayrı çalıştırılabilir. Rules deployment CI içinde tutulmalıdır.

App Check

Flutter App Check platforma göre attestation provider kullanabilir. Android Play Integrity ve Apple App Attest seçenekleri release build'de uygulanabilir. Debug provider local development için gerekir. Enforcement öncesi metrics izlenir. User authentication ayrı katman olarak kalır.

Android/Kotlin ile Firebase Entegrasyonu

Android Kotlin uygulamalarında Firebase SDK Authentication, Firestore, Realtime Database ve App Check servislerini platform lifecycle'ıyla entegre eder. Coroutines veya Flow wrapper listener data'yı reactive architecture'a taşıyabilir. Activity veya ViewModel lifecycle subscription ownership'i açık biçimde yönetmelidir. Android Firestore offline persistence default olarak aktif olduğu için sensitive cache policy ayrıca değerlendirilmelidir. Play Integrity App Check production abuse protection için kullanılabilir.

Firebase SDK

Android Gradle dependencies yalnız kullanılan Firebase servislerini içermelidir. BoM compatible version yönetimini kolaylaştırabilir. App initialization application startup'ta yapılır. Multiple process kullanımı özel test gerektirebilir. Release build minification Firebase config davranışını bozmamalıdır.

Authentication

FirebaseAuth currentUser ve auth state listener sağlar. UI loading state persisted session restore ile uyumlu olmalıdır. ID token backend request için alınabilir. Account disable veya token revoke scenario handle edilmelidir. Deep link authentication flow security review almalıdır.

Flow / Listener

Firestore listener callback Kotlin Flow'a dönüştürülebilir. Collector lifecycle-aware çalışmalıdır. Cancel olduğunda underlying listener kaldırılmalıdır. Duplicate collection aynı data için yeni listener açmamalıdır. Error Flow'a iletilip UI state'e çevrilir.

Offline Persistence

Firestore Android'de offline persistence varsayılan olarak aktiftir. Cached data offline read ve listener'a hizmet eder. Sensitive data device storage içinde kalabilir. Logout sonrası UI cache isolation test edilmelidir. App-specific encryption requirement ayrıca değerlendirilebilir. :contentReference[oaicite:54]{index=54}

App Check

Play Integrity Android App Check provider olarak kullanılabilir. Debug emulator için debug provider gerekir. Enforcement açılmadan metrics incelenir. Invalid token error telemetry version bazında segmentlenebilir. Security Rules user permission'ını yine enforce eder.

NestJS / Node.js Backend ile Firebase Entegrasyonu

NestJS veya Node.js backend Firebase Authentication'ı identity provider olarak kullanıp Admin SDK ile token verification ve privileged database access sağlayabilir. Request guard Authorization header'daki ID token'ı verify eder ve trusted UID'yi request context'e ekler. Role guard custom claims veya database membership üzerinden authorization yapabilir. Admin SDK Rules'u bypass ettiği için service layer her resource access'te user scope'unu kontrol etmelidir. Service account secret yalnız server environment'ta kalmalıdır.

Firebase Admin SDK

Admin SDK application bootstrap sırasında bir kez initialize edilir. Cloud environment application default credential kullanılabilir. Local development service account secret manager üzerinden alınabilir. Firestore veya Auth service dependency injection ile paylaşılabilir. Client bundle'a hiçbir admin credential çıkmamalıdır.

ID Token Guard

NestJS Guard request header token'ını alır ve Admin Auth verify çağrısı yapar. Missing veya invalid token Unauthorized response üretir. Decoded token request user context'e yazılır. Raw token log edilmez. Revocation check risk seviyesine göre eklenebilir.

UID Extraction

UID decoded verified token'dan alınır. Client query parameter içindeki UID identity olarak kullanılmaz. Target user ID farklı operation için ayrıca authorization gerektirir. Audit log actor UID'yi verified context'ten yazar. Testing forged body UID scenario'yu kapsar.

Custom Claims

Decoded token custom claim role bilgisi içerebilir. Guard role metadata ile karşılaştırabilir. Claim outdated olabilir ve token refresh gerekir. Organization membership frequently changing ise database lookup yapılabilir. Admin claim endpoint yalnız trusted actor tarafından kullanılabilir.

Role-Based Authorization

Role guard route metadata üzerinden required role kontrol edebilir. Resource ownership service layer'da ayrıca doğrulanır. Global admin ile tenant admin ayrılır. Deny default behavior olmalıdır. Authorization test e2e suite içinde farklı token claim'leriyle çalıştırılır.

Admin SDK ile Veri Erişimi

Backend Admin Firestore client resource read veya write yapabilir. Rules bypass edildiği için query current user tenant scope'una açıkça filtrelenir. Direct document fetch sonrası membership check yapılabilir. User-controlled document path sanitize edilir. Data response minimum field set ile client'a döndürülür.

Firebase İçin Hangi Programlama Dili Kullanılmalı?

Firebase için en iyi programlama dili tek bir cevap taşımaz çünkü client platform ve backend sorumluluğu seçimi belirler. Web için JavaScript veya TypeScript, Flutter için Dart, Android için Kotlin, Apple platformları için Swift doğal seçeneklerdir. Admin SDK tarafında Node.js, Java, Python, Go ve C# gibi ekosistemler kullanılabilir. Önemli olan dilin Firebase API desteği yanında ekibin domain bilgisi, observability, test ve deployment altyapısıyla uyumudur. Firebase seçimi dil bağımsız BaaS kararıyla birlikte değerlendirilmelidir.

JavaScript / TypeScript

Web client ve Node.js backend için en doğal kombinasyonlardan biridir. Firebase modular Web SDK TypeScript type desteği sunar. Cloud Functions Node runtime ile yakın entegrasyon vardır. Strict type model Firestore document schema'yı tamamen runtime validate etmez. Security Rules yine server-side validation sağlar.

Dart / Flutter

Dart Flutter uygulamalarda Firebase servislerini FlutterFire üzerinden kullanır. Single codebase Android, iOS ve web target'larına ulaşabilir. Platform-specific App Check ve auth provider config yine native seviyede farklıdır. Stream API realtime data için uygundur. Rules platformdan bağımsız aynı backend policy'yi uygular.

Kotlin

Kotlin Android uygulamalarında modern coroutine ve Flow yaklaşımıyla Firebase listener'larını yönetebilir. Null safety data mapping hatalarını azaltır. Offline persistence Android client avantajıdır. Play Integrity App Check platform security ile uyumludur. Backend yine farklı dilde olabilir.

Swift

Swift iOS ve Apple platform Firebase SDK'larıyla doğal integration sağlar. Async-await ve listener wrapper kullanılabilir. App Attest App Check provider olarak uygulanabilir. Keychain ve session lifecycle native security modeline göre yönetilir. Firestore Rules bütün client platformlarında aynı permission modelini korur.

Java

Java Android legacy codebase veya server Admin SDK ortamında kullanılabilir. Firebase'in uzun süredir desteklediği ekosistemlerden biridir. Kotlin ile interoperability migration kolaylaştırır. Server authorization aynı verified ID token modelini izler. Language seçimi Rules davranışını değiştirmez.

Python / Go / C# Admin SDK Kullanımı

Python, Go ve C# trusted backend veya worker servislerinde Firebase Admin SDK kullanabilir. Token verification, user management ve database operation aynı identity modeline dayanır. Runtime seçimi ekibin infrastructure ve performance ihtiyacına göre yapılır. Server client Firestore Rules'u bypass edeceği için application authorization unutulmamalıdır. Service account credential management bütün dillerde aynı derecede kritiktir.

“En İyi Programlama Dili” Yerine Doğru Client/Backend Stack Nasıl Seçilir?

Önce target platform, realtime requirement, team experience ve deployment environment yazılır. Web-heavy ürün TypeScript client ve Node backend ile hızlı ilerleyebilir. Mobile-first product Flutter veya native stack seçebilir. Complex analytics backend Python veya Go olabilir. Stack seçimi ekibin güvenlik ve test standardını sürdürebileceği teknoloji üzerinden yapılmalıdır.

Firebase mi Özel Backend mi?

Firebase ile özel backend seçimi “hangisi daha profesyonel?” sorusundan çok domain ve operasyon gereksinimiyle ilgilidir. Firebase hızlı MVP, realtime feature, mobile-first app ve direct client data access için büyük geliştirme hızına sahip olabilir. Karmaşık domain workflow, yoğun relational transaction, özel database portability veya ileri network control özel backend'i daha uygun hale getirebilir. Hybrid architecture client-facing realtime feature'larda Firebase kullanıp critical business logic'i özel backend'de tutabilir. Karar maliyet, lock-in, ekip yetkinliği ve veri modelinin uzun vadeli yönüyle birlikte verilmelidir.

Hızlı MVP

Authentication, Firestore ve Storage hazır servisleri MVP'nin backend altyapısını hızla kurabilir. Ekip product validation'a daha erken odaklanır. Ancak test mode ile production'a çıkılmamalıdır. Security Rules başlangıçtan yazılmalıdır. MVP başarılı olduğunda data model'in büyümeye uygun olup olmadığı gözden geçirilmelidir.

Realtime Applications

Chat, live task board veya presence Firebase'in güçlü kullanım alanlarıdır. Listener API polling kodunu azaltır. Offline cache user experience'i destekleyebilir. Scale'de listener maliyeti izlenmelidir. High-frequency telemetry için farklı stream infrastructure gerekebilir.

Mobile-First Applications

Firebase Authentication, push ecosystem, offline persistence ve platform SDK'ları mobile-first development hızını artırabilir. Android ve iOS network kesintisinde local data kullanabilir. App Check mobile attestation ile abuse protection ekler. Client direct access Rules ile korunur. Backend privileged action'lar için yine gerekebilir.

Karmaşık Domain Logic

Bir işlem birçok entity ve external system arasında strict consistency gerektiriyorsa özel backend daha anlaşılır olabilir. Client Rules içine business workflow'un tamamını koymak doğru değildir. Backend transaction, saga veya queue pattern kullanabilir. Firebase data source olarak yine kullanılabilir. Domain logic ownership server code'da tutulabilir.

Database Portability

Firestore document model ve SDK semantics product code'a bağlandıkça farklı database'e migration maliyeti artabilir. Repository abstraction bazı bağımlılıkları azaltır. Ancak aşırı generic abstraction Firebase özelliklerini kullanmayı zorlaştırabilir. Portability gerçek requirement ise data export ve migration plan erkenden yazılmalıdır. Vendor lock-in riskinin parasal değeri objektif değerlendirilmelidir.

Vendor Lock-In

Authentication, Security Rules, realtime listener ve serverless function birlikte kullanıldığında platform bağımlılığı artar. Bu tek başına kötü değildir; managed capability karşılığında alınan trade-off'tur. Exit strategy critical product'larda belgelenebilir. Data export format ve business logic portability incelenir. Ekip gereksiz provider-specific shortcut yerine clear domain model koruyabilir.

Maliyet ve Ölçek

Firebase küçük ve orta scale'de operasyon maliyetini azaltabilir. Büyük scale'de read-heavy realtime query veya bandwidth maliyeti önemli hale gelebilir. Özel backend infrastructure da server, database, DevOps ve on-call maliyeti taşır. Sadece cloud invoice karşılaştırmak eksiktir. Total engineering cost ve reliability birlikte değerlendirilmelidir.

Hybrid Architecture

Hybrid model Firestore'u user-facing realtime data için, özel backend'i payment, reporting veya domain transaction için kullanabilir. Backend Firebase ID token verify ederek aynı identity sistemini kullanır. Data consistency boundary açık tanımlanmalıdır. Event-driven synchronization gerekebilir. Hangi sistem source of truth net olmalıdır.

Firebase Maliyeti Nasıl Kontrol Edilir?

Firebase maliyeti kullanıcı sayısından çok kullanıcı başına yapılan read, write, listener, storage ve bandwidth davranışıyla belirlenir. Firestore document read sayısı, Realtime Database data transferi ve Cloud Functions invocation gibi ölçüler feature tasarımından doğrudan etkilenir. Query scope daraltmak, duplicate listener kapatmak ve binary asset'i Storage üzerinde tutmak temel optimizasyonlardır. Budget alert production sürprizlerini azaltır. Güncel fiyat rakamları değişebileceği için release ve capacity plan sırasında resmi pricing sayfalarıyla doğrulanmalıdır.

Document Reads

Firestore query sonucundaki document read miktarı maliyetin önemli parçasıdır. Realtime listener sık değişen result set'te read sayısını büyütebilir. Broad collection listener yerine filtered query kullanılmalıdır. Cache behavior tekrar fetch'i azaltabilir. Dashboard user başına read trendini izlemelidir.

Writes

Her keystroke database write yapmak gereksiz olabilir. Form draft debounce veya explicit save kullanabilir. Presence update frequency sınırlandırılabilir. Batch write birden fazla operation'ı birlikte yürütür, ancak billing semantics yine write başına değerlendirilebilir. High-frequency write hotspot oluşturabilir.

Realtime Listeners

Listener value sağladığı ekranlarla sınırlandırılmalıdır. Hidden page subscription kapatılır. User aynı data için birden fazla listener açmamalıdır. Query result limit uygulanabilir. Listener usage release sonrası cost dashboard'da izlenir.

Bandwidth

Large document veya RTDB subtree transferi network maliyeti oluşturur. Binary file database'e konmamalıdır. User'ın ihtiyacı olmayan field ayrı resource'a taşınabilir. Image CDN ve Storage kullanılır. Mobile low-bandwidth user experience'i de iyileşir.

Storage

Document, index ve file storage büyüdükçe maliyet artabilir. Firestore gereksiz composite index'ler storage kullanır. Old logs retention policy ile temizlenir. Storage orphan file cleanup scheduled job gerektirebilir. Backup requirement ayrıca maliyet oluşturabilir.

Cloud Functions

Function invocation, compute duration ve external network cost usage'a bağlıdır. Her small write için gereksiz trigger zinciri oluşturmamak gerekir. Idempotent function duplicate event riskini yönetir. Region database'e yakın seçilebilir. Cold start-sensitive endpoint performance test edilmelidir.

Query Scope

User yalnız current tenant data'sını query etmelidir. Time range ve pagination result size'ı sınırlar. Broad admin reporting client listener yerine backend aggregate kullanabilir. Index query efficiency sağlar. Security condition ve cost optimization çoğu zaman aynı query shape'ten faydalanır.

Budget Alerts

Google Cloud billing budget alert belirli harcama threshold'larında ekibi uyarabilir. Alert harcamayı otomatik durdurmayabilir, ancak erken incident signal verir. Daily cost anomaly takip edilebilir. Marketing campaign veya feature release öncesi expected usage artırılır. Abuse spike App Check ve rate limit ihtiyacını gösterebilir.

Firebase Monitoring ve Observability

Firebase production sisteminde yalnız console'da data görünmesi yeterli değildir. Usage dashboard, database profiler, Cloud Monitoring, authentication error, permission-denied, App Check metrics ve cost anomaly birlikte izlenmelidir. Authorization error artışı yeni Rules deployment'ından kaynaklanabilir. Read spike duplicate listener bug gösterebilir. Observability teknik metriği user flow ve release version ile ilişkilendirdiğinde incident çözümü hızlanır.

Usage Dashboard

Firebase console usage metricleri read, write, storage veya connection trendlerini ürün bazında gösterebilir. Release tarihiyle usage spike karşılaştırılır. Daily ve monthly pattern incelenir. Sudden growth user artışı mı bug mı ayrıştırılır. Budget planning historical data kullanır.

Realtime Database Profiler

Realtime Database profiler database operation ve bandwidth behavior hakkında insight sağlayabilir. Broad path read kolayca fark edilebilir. Query index ihtiyacı görülebilir. Production profiling sensitive data göstermeyecek şekilde kullanılmalıdır. Optimization sonrası before-after ölçüm alınır.

Cloud Monitoring

Google Cloud Monitoring backend service, function ve infrastructure metric'lerini merkezi dashboard'a taşıyabilir. Latency, error rate ve invocation count alarm üretir. Firebase usage ile backend metric korelasyonu yapılabilir. SLO tanımları incident priority belirler. Alert fatigue önlemek için meaningful threshold seçilir.

Authentication Errors

Sign-in failure provider config, quota, user credential veya abuse nedeniyle artabilir. Error code aggregate izlenir. Raw password veya token loglanmaz. Version-specific issue rollout bug'ını gösterir. Account recovery error'ları user support trendine bağlanabilir.

Permission-Denied Errors

Permission denied rate Rules deployment sonrası yükselirse query veya role regression olabilir. Client error telemetry route, operation ve sanitized resource type içerebilir. Sensitive path veya document content loglanmamalıdır. Staging reproduction yapılır. Unauthorized attack traffic ile legitimate denial ayrıştırılır.

App Check Metrics

App Check valid ve invalid request oranı enforcement öncesi kritik sinyaldir. Old app version token üretmiyor olabilir. Bot traffic invalid request oranını yükseltebilir. Provider quota takip edilir. Enforcement açıldıktan sonra reject spike alert üretebilir.

Cost Anomalies

Beklenmedik read veya bandwidth artışı bug ya da abuse gösterebilir. Daily cost baseline oluşturulabilir. Feature flag release ile anomaly korelasyonu incelenir. Listener count veya query behavior source bulunur. Budget alert incident channel'ına bağlanabilir.

Open Source Firebase Ekosistemi

Firebase ekosistemi resmi SDK'ların yanında açık kaynak community library, emulator tooling, starter kit ve test yardımcılarıyla geniştir. Open source kullanırken package maintenance, security update ve SDK version compatibility kontrol edilmelidir. Authentication veya Security Rules gibi kritik alanlarda community abstraction underlying Firebase behavior'ını gizlememelidir. Emulator Suite local development ve güvenlik eğitimi için özellikle değerlidir. Ekip kaynak kodu okuyarak listener lifecycle ve rule testing konusunda daha derin bilgi kazanabilir.

Firebase SDK'ları

Firebase client ve Admin SDK'larının birçok parçası açık kaynak repository'lerde geliştirilmektedir. Issue tracker real-world edge case'leri anlamaya yardımcı olabilir. Upgrade öncesi changelog incelenir. Internal wrapper resmi API behavior'ından gereksiz uzaklaşmamalıdır. Security fix release'leri dependency automation ile takip edilebilir.

FirebaseUI

FirebaseUI authentication screen ve common auth UX için hazır bileşenler sağlayabilir. Product brand veya accessibility requirement'a göre özelleştirme gerekebilir. Library maintenance status ve platform compatibility kontrol edilmelidir. Authentication UI hazır olsa bile authorization Rules ayrıca yazılır. Account linking ve error state test edilir.

Emulator Suite

Emulator Suite open development workflow içinde production resource'a dokunmadan Firebase behavior test etmeye yardımcı olur. Security Rules testleri en değerli kullanım alanlarından biridir. Local Functions ve database integration geliştirilebilir. CI automation aynı emulator config'i çalıştırabilir. Seed data deterministic tests sağlar.

Community Packages

Community package developer experience'i artırabilir. Ancak package auth token, Firestore query veya listener lifecycle'ını nasıl yönettiği incelenmelidir. Abandoned dependency production riskidir. Bundle size ve platform support değerlendirilir. Critical security abstraction yerine official SDK doğrudan kullanımı tercih edilebilir.

FlutterFire

FlutterFire Firebase'in Flutter ekosistemiyle entegrasyonunda temel package setidir. Platform channel ve native Firebase SDK behavior'ını Dart API'ye taşır. Version compatibility release notes ile takip edilir. Community issue'ları platform-specific bug hakkında bilgi sağlayabilir. App Check ve offline behavior gerçek cihazda test edilmelidir.

React Firebase Libraries

React community Firebase hook veya query abstraction paketleri sunar. Cache, suspense ve listener cleanup developer deneyimini kolaylaştırabilir. Underlying query security requirement yine değişmez. Library broad query yapıyorsa Rules permission denied verebilir. Bundle ve maintenance cost değerlendirilmelidir.

Açık Kaynak Rule Test Araçları

Firebase Emulator test SDK'sı Rules unit testlerini programatik hale getirir. Community helper'lar permission matrix case generation sağlayabilir. Test abstraction expected allow ve deny sonucu gizlememelidir. CI output hangi path ve auth context'in fail olduğunu açık göstermelidir. Rule testing developer onboarding'e dahil edilmelidir.

Open Source ve İşbirliğinin Firebase Projelerindeki Rolü

Firebase projelerinde açık kaynak çalışma yalnız package kullanmak değil security rule, starter kit ve test pattern'lerini ekipler arasında paylaşmak anlamına gelir. GitHub contribution gerçek bug ve integration scenario görmeyi sağlar. Inner-source repository organization içindeki ekiplerin ortak Firebase altyapısını birlikte geliştirmesine yardımcı olabilir. Security Rules template kör şekilde kopyalanmamalı, her product permission matrix'ine göre uyarlanmalıdır. Code review ve architecture discussion Firebase yetkinliğinin ekip içinde yayılmasını sağlar.

GitHub Üzerinden Katkı

SDK issue reproduce etmek Firebase behavior'ını derin anlamayı sağlar. Documentation improvement veya example contribution da değerlidir. Contribution test discipline öğretir. Community discussion farklı platform edge case'lerini gösterir. Internal team öğrendiklerini ADR veya workshop olarak paylaşabilir.

Ortak Security Rules Şablonları

Organization-wide helper function veya owner pattern template başlangıç noktası olabilir. Her project aynı role ve data model'e sahip olmadığı için template final policy değildir. Default deny pattern korunur. Test matrix template ile birlikte sağlanabilir. Security team shared rule review checklist oluşturabilir.

Firebase Starter Kit'leri

Starter kit auth initialization, environment separation ve emulator setup gibi tekrarlanan işleri hızlandırabilir. Broad demo Rules production starter kit'e konmamalıdır. App Check placeholder ve CI test skeleton eklenebilir. New project ilk günden security baseline alır. Upgrade sorumluluğu platform ekibine verilebilir.

Emulator Tabanlı Eğitim Projeleri

Developer production credential kullanmadan owner ve attacker scenario test edebilir. Workshop User A ve User B oluşturup horizontal access deneyebilir. Rules değişikliği sonucu anında görülebilir. Presence ve offline behavior ayrı lab yapılabilir. Learning repo public sample data kullanabilir.

Security Rule Code Review

Rule review frontend code review kadar önemli olmalıdır. Broad wildcard, unauthenticated allow veya mutable role field aranır. Query shape permission condition ile karşılaştırılır. Negative test yoksa review eksik sayılabilir. Reviewer business permission matrix'e erişebilmelidir.

Community Best Practices

Community pattern'leri useful olsa da official Firebase docs ile doğrulanmalıdır. Eski blog post eski SDK veya security behavior kullanabilir. Date ve version kontrol edilir. Production decision current official reference'e dayanır. Internal knowledge base güncel linklerle yenilenir.

Diyarbakır Yazılım Topluluğu İçin Firebase Proje Fikirleri

Firebase öğrenmenin en kalıcı yollarından biri authentication, realtime data ve Security Rules'u birlikte kullanan küçük ama gerçek bir proje geliştirmektir. Diyarbakır Yazılım Topluluğu içinde chat, etkinlik presence, task management veya açık kaynak mobil application gibi projeler farklı yetenek seviyesindeki geliştiricileri aynı repository etrafında buluşturabilir. Her proje yalnız feature geliştirme değil permission matrix, emulator test ve App Check workshop'u içermelidir. Böylece Firebase entegrasyonu ve backend danışmanlığı yakınımda gibi bir ihtiyaç arayan geliştiriciler teorik anlatım yerine çalışan örnekler üzerinden öğrenebilir. Topluluğun mevcut proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden incelemek mümkündür.

Gerçek Zamanlı Topluluk Sohbeti

Topluluk chat projesi Authentication, Firestore veya Realtime Database listener ve moderation role'ünü birlikte öğretir. User yalnız kendi message'ını edit edebilir. Moderator reported message'ı hide edebilir. Rate limiting ve App Check abuse riskini azaltır. Emulator different-user testleri horizontal access'i doğrular.

Etkinlik Katılım ve Presence Sistemi

Event attendance Firestore üzerinde kayıt tutulurken live presence Realtime Database ile modellenebilir. onDisconnect() connection cleanup sağlar. User yalnız kendi attendance status'ını değiştirebilir. Organizer aggregate view backend veya trusted query üzerinden oluşturulur. QR check-in gibi feature authorization lab'e dönüştürülebilir.

Ortak Görev Yönetim Uygulaması

Task app organization, project membership ve owner authorization öğretmek için uygundur. User kendi task'ını oluşturabilir. Editor project içindeki assigned task'ları update edebilir. Cross-project access emulator testle engellenir. Offline write ve optimistic UI ayrıca incelenebilir.

Firebase Security Rules Workshop'u

Workshop yalnız syntax anlatmak yerine saldırgan senaryolarla ilerlemelidir. Önce insecure rule yazılır ve User B'nin User A data'sını okuması gösterilir. Sonra owner ve tenant rule uygulanır. Query rules are not filters behavior live test edilir. CI emulator tests final bölümde eklenir.

Flutter + Firebase Açık Kaynak Mobil Uygulaması

Flutter app Authentication, Firestore stream, offline persistence ve App Check pratiği sağlar. Android ve iOS build aynı data model'i kullanır. Security Rules platformdan bağımsız enforcement gösterir. Contribution guide yeni geliştiricilerin küçük issue almasını kolaylaştırır. Release pipeline open source CI deneyimi sağlar.

App Check ve Authorization Laboratuvarı

Lab Authentication, App Check ve Security Rules farkını somut olarak gösterir. Valid App Check token taşıyan ama başka user resource'una erişmeye çalışan request yine deny olur. Authenticated olmayan valid app request public resource'a erişebilir. Fake client App Check enforcement ile reject edilir. Bu deney güvenlik katmanlarının rollerini kalıcı biçimde öğretir.

Yazılımcı Olmak İsteyenler Firebase'i Nasıl Öğrenmeli?

Firebase öğrenmeye doğrudan console butonlarından değil JavaScript, TypeScript veya seçilen mobil dilin temel programlama kavramlarından başlamak daha sağlıklı olur. Sonra Authentication, NoSQL data modeling, Firestore, Realtime Database ve Security Rules sırasıyla çalışılabilir. Emulator Suite production risk olmadan güvenlik denemeleri yapmak için erken aşamada öğrenilmelidir. Açık kaynak proje katkısı gerçek code review ve integration hatalarıyla karşılaşmayı sağlar. Topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi incelenebilir.

JavaScript/TypeScript veya Mobil Dil Temelleri

Async operation, promise, stream, function ve data structure temelleri bilinmeden Firebase SDK ezbere dönüşebilir. Web developer TypeScript ile type model öğrenebilir. Flutter developer Dart stream ve async yapısını anlamalıdır. Android developer coroutine ve lifecycle bilgisine ihtiyaç duyar. Firebase bu temellerin üzerine kurulmalıdır.

Authentication

Önce email-password signup ve login flow uygulanabilir. Auth state listener öğrenilir. UID ile user-specific document bağlanır. Logout ve token refresh gözlemlenir. Sonra social provider ve custom claim eklenebilir.

NoSQL Veri Modelleme

Relational join alışkanlığı Firestore veya Realtime Database'e doğrudan taşınmamalıdır. Query-driven data modeling öğrenilmelidir. Denormalization trade-off anlaşılmalıdır. Ownership ve tenant ID data model'e dahil edilmelidir. Index ihtiyacı query ile birlikte düşünülmelidir.

Firestore

Collection, document, query ve onSnapshot temel konulardır. Sonra offline persistence ve metadata incelenir. Security Rules baştan yazılır. Composite index experiment yapılır. Emulator farklı auth context ile test edilir.

Realtime Database

JSON tree model ve path-based access öğrenilir. Value ve child listener farkı denenir. /.info/connected ile presence geliştirilir. Rules cascading behavior özellikle test edilir. .indexOn query performance için uygulanır.

Security Rules

İlk rule default deny olmalıdır. User owner path erişimi yazılır. Different-user malicious request test edilir. Firestore Rules filtre değildir davranışı query üzerinden görülür. Admin claim ve immutable field daha sonra eklenir.

Emulator Suite

Local Auth ve database emulator development confidence sağlar. Production project credential kullanılmaz. Rule tests CI'a taşınır. Seed data deterministic scenario yaratır. Function integration aynı environment'da test edilebilir.

Açık Kaynak Projelere Katkı

Starter issue listener cleanup veya rule test gibi küçük alanda olabilir. Pull request review kod standardı öğretir. Documentation contribution Firebase concept'lerini açıklamayı geliştirir. Security bug report responsible disclosure policy'ye uymalıdır. Community collaboration teknik iletişim becerisini güçlendirir.

Örnek Bir Production-Ready Firebase Projesi Nasıl Kurulur?

Production-ready Firebase projesi yalnız SDK initialization ve bir login ekranından oluşmaz. Environment separation, authentication provider, authorization matrix, database seçimi, data model, Security Rules, realtime listener, offline strategy, App Check, admin backend, emulator test, CI/CD, monitoring ve cost review birlikte tasarlanmalıdır. Bu adımları sırayla yürütmek güvenlik kararlarının son dakikaya kalmasını önler. Her adımın acceptance criteria ve owner'ı bulunmalıdır. Architecture Decision Record database ve authorization kararını gelecekteki ekip üyeleri için belgeleyebilir.

Adım 1 — Firebase Projesini Oluşturma

Önce development Firebase project oluşturulur. IAM access ekip rolleriyle sınırlandırılır. Region ve billing ihtiyacı belirlenir. Kullanılacak Firebase products listelenir. Production project henüz development data ile karıştırılmaz.

Adım 2 — Dev/Prod Ortamlarını Ayırma

Development ve production ayrı project ID kullanır. Firebase config build environment'a göre seçilir. CI target yanlış project'e deploy etmeyi engeller. Staging gerekiyorsa üçüncü project eklenir. Data export production'dan dev'e kişisel veri taşımamalıdır.

Adım 3 — Authentication Provider'ları

Required login yöntemleri product persona'ya göre seçilir. Email verification ve recovery flow hazırlanır. Social provider redirect domain test edilir. Anonymous account linking gerekiyorsa tasarlanır. Admin user MFA policy ayrıca belirlenir.

Adım 4 — Authorization Matrix

Guest, user, owner, editor ve admin operation tablosu yazılır. Resource listesi çıkarılır. Read, create, update ve delete sonucu belirlenir. Cross-tenant access explicit deny olur. Matrix emulator test case'lerine dönüşür.

Adım 5 — Firestore veya RTDB Seçimi

Query, presence, offline, scaling ve cost requirement karşılaştırılır. General document data Firestore seçebilir. Presence RTDB kullanabilir. İki database birlikte kullanılacaksa source of truth ayrımı yazılır. Seçim ADR ile belgelenir.

Adım 6 — Data Model

Collection, document veya RTDB path query ihtiyacına göre oluşturulur. Owner UID ve tenant ID nerede tutulacağı belirlenir. Sensitive field ayrı resource'a taşınabilir. Index requirement listelenir. Migration ve retention policy düşünülür.

Adım 7 — Security Rules

Rules default deny ile başlar. Authentication, ownership ve role condition eklenir. Incoming data validation yazılır. Broad wildcard kaçınılır. Rules repository içinde tutulur.

Adım 8 — Realtime Listeners

Hangi ekran gerçekten realtime olmalı belirlenir. Query scope dar tutulur. Listener lifecycle documented olur. Duplicate subscription önlenir. Cost ve render behavior load test edilir.

Adım 9 — Offline Strategy

Hangi data offline okunabilir ve yazılabilir belirlenir. Firestore web persistence shared-device policy ile ele alınır. Pending sync state UI'a eklenir. Conflict behavior test edilir. Sensitive operation offline queue'ya alınmaz.

Adım 10 — App Check

Target platform attestation provider seçilir. Development debug provider kullanır. Metrics enforcement öncesi izlenir. Old client version uyumu kontrol edilir. Staged enforcement production'da açılır.

Adım 11 — Admin Backend

Role assignment, webhook ve privileged operation backend'e taşınır. ID token middleware verify yapar. IAM least privilege uygulanır. Admin SDK Rules bypass davranışı nedeniyle application authorization yazılır. Audit log critical action'ları kaydeder.

Adım 12 — Emulator Tests

Rules permission matrix automated tests'e dönüşür. Authenticated, owner ve different-user scenarios çalışır. Invalid data payload test edilir. Functions integration local emulators ile denenir. Test fixture production personal data kullanmaz.

Adım 13 — CI/CD

Pull request unit ve rules tests çalıştırır. Staging deployment automatic olabilir. Production manual approval gerektirebilir. Rule ve function deployment versionlanır. Rollback command documented olur.

Adım 14 — Monitoring

Auth error, permission denied, App Check metrics ve backend latency dashboard hazırlanır. Cost alert eklenir. Release version telemetry'e bağlanır. Incident threshold belirlenir. Log privacy review yapılır.

Adım 15 — Cost ve Security Review

Production öncesi query read count, listener scope ve bandwidth tahmini yapılır. Rules broad access scan edilir. Service account key ve environment secret kontrol edilir. KVKK data inventory gözden geçirilir. Low-risk rollback ve incident playbook tamamlanır.

Firebase Entegrasyonlarında Yapılan Yaygın Hatalar

Firebase entegrasyonlarında yapılan hatalar çoğunlukla Authentication, authorization ve server privilege sınırlarının birbirine karıştırılmasından kaynaklanır. Kullanıcı login oldu diye bütün database'i açmak, Rules'u sonradan yazmak veya client role control'üne güvenmek ciddi risk oluşturur. Realtime listener scope ve index tasarımını ihmal etmek maliyet sorununa dönüşebilir. Admin SDK'nın Rules'u bypass ettiği unutulduğunda backend tarafında cross-tenant data leak ortaya çıkabilir. Production checklist bu riskleri release öncesi sistematik olarak kontrol etmelidir.

Authentication'ı Authorization Sanmak

Login user identity sağlar. Resource permission ayrıca gerekir. auth != null broad collection read için yeterli değildir. Ownership veya role condition eklenmelidir. Different-user test bu hatayı yakalar.

Test Mode'u Production'da Bırakmak

Test mode development kolaylığı sağlar ama real user data için uygun değildir. Production deploy öncesi explicit Rules uygulanır. Console warning takip edilir. CI broad allow scan yapabilir. Staging production-like Rules kullanır.

Security Rules'u Sonradan Yazmak

Data model authorization ihtiyacını taşımıyorsa sonradan güvenli Rules yazmak zor olabilir. Owner ID veya tenant path baştan düşünülmelidir. Query Rules ile birlikte tasarlanır. Permission matrix project kickoff'ta hazırlanabilir. Security feature değil architecture concern olarak ele alınmalıdır.

Rules'u Filter Sanmak

Firestore broad collection query unauthorized documents'ı Rules ile filtreleyemez. Request tamamen deny olabilir. Query constraint authorization condition'ı taşımalıdır. Realtime Database parent read de child allow/deny ile partial result üretmez. Data access layer safe query oluşturmalıdır.

Client-Side Role Kontrolüne Güvenmek

Client role variable manipüle edilebilir. Hidden button doğrudan network request'i durdurmaz. Trusted custom claim veya membership server tarafında kontrol edilir. Backend verified token kullanır. UI role yalnız presentation içindir.

Admin SDK'nın Rules'u Bypass Ettiğini Unutmak

Admin SDK Firestore client Rules'a uymaz. Backend bütün data'ya erişebilecek credential taşıyabilir. Endpoint user token ve resource membership kontrol etmelidir. IAM least privilege uygulanır. Integration test cross-tenant access'i reddeder. :contentReference[oaicite:55]{index=55}

Bütün Collection'ı Realtime Dinlemek

Large collection listener yüksek read ve render maliyeti oluşturur. User filter ve limit kullanılmalıdır. Historical data pagination ile alınabilir. Admin analytics realtime olmak zorunda değildir. Cost monitoring listener davranışını gösterir.

Listener'ları Kapatmamak

Unmount olan component listener'ı açık bırakırsa duplicate subscription birikebilir. Logout eski user data event almaya devam edebilir. Unsubscribe lifecycle zorunludur. Network profiler active listener'ı gösterir. Central subscription manager kullanılabilir.

Index Tasarımını Sonradan Düşünmek

Query production'da missing composite index error verebilir. Critical query staging'de çalıştırılmalıdır. RTDB orderByChild field için .indexOn gerekir. Unused index gereksiz maliyet oluşturabilir. Query inventory index planını yönlendirir.

App Check'i Authorization Yerine Kullanmak

Valid App Check token user'ın resource permission'ı olduğunu göstermez. Sahte client abuse azaltılır. User A valid app ile User B document'ını isteyebilir. Security Rules UID veya membership üzerinden deny eder. Authentication ve App Check ayrı signal'lardır.

Custom Claims İçinde Profil Verisi Tutmak

Custom claims yalnız access-control için kullanılmalıdır. Profile field token size'ı büyütür. Güncel Firebase dokümantasyonu claim payload için 1000 byte limit belirtir. Frequently changing data token refresh gerektirir. Profile Firestore document'ında tutulmalıdır. :contentReference[oaicite:56]{index=56}

Offline Cache'deki Hassas Veriyi Unutmak

Web persistent Firestore cache session sonrasında data tutabilir. Shared device risk oluşturur. Trusted device policy uygulanabilir. Logout UI memory state'i temizler, disk cache strategy ayrıca gerekir. Sensitive document client'a hiç gönderilmemesi en güçlü korumadır.

Service Account Key'i Client'a Koymak

Service account key privileged backend credential'dır. Browser bundle veya mobile binary içinde saklanamaz. Key exposed olduğunda revoke edilmelidir. Admin operation server'a taşınır. Managed identity static key ihtiyacını azaltabilir.

Firebase'in Geleceği ve Modern Backend Yaklaşımları

Firebase'in modern backend yaklaşımındaki yönü client-direct data access, managed realtime synchronization, app attestation ve serverless compute'u birlikte kullanmaya devam ediyor. Bunun yanında Cloud Run gibi özel backend servisleriyle hybrid mimari kurmak giderek daha normal hale geliyor. Policy ve Security Rules test otomasyonu production güvenliği için önemli rol oynuyor. Generative AI veya agentic application gibi yeni kullanım alanlarında da authentication, authorization, quota ve App Check temel güvenlik konuları olmaya devam ediyor. Yeni servis eklemek eski güvenlik ilkelerini ortadan kaldırmıyor, aksine resource sınırlarını daha açık tanımlamayı gerektiriyor.

Serverless Realtime Applications

Client SDK realtime database'e direct access sağlayabilir. Serverless function privileged workflow'u yürütür. Traditional always-on API ihtiyacı bazı feature'larda azalır. Observability ve cost model hâlâ gereklidir. Hybrid backend gerektiğinde kolayca eklenebilir.

Stronger App Attestation

App Check provider'ları device ve app authenticity signal'larını güçlendirmeye devam ediyor. Ağustos 2026 dokümantasyonunda reCAPTCHA Enterprise, Play Integrity ve App Attest öne çıkıyor. Enforcement coverage zamanla genişleyebilir. Feature status release öncesi resmi docs ile kontrol edilmelidir. Authorization yine ayrı policy'dir. :contentReference[oaicite:57]{index=57}

Client-Side Data Access + Policy Enforcement

Firebase'in karakteristik modeli client'ın data service'e doğrudan erişirken server-side policy'nin request'i enforce etmesidir. Bu yaklaşım CRUD API boilerplate'ini azaltır. Policy query model ile birlikte tasarlanır. Rules as code ve test automation önem kazanır. Privileged server operation ayrı kalır.

Offline-First Applications

Mobil kullanıcılar unstable network altında application kullanmaya devam etmek ister. Firestore offline persistence bu deneyimi destekler. Local pending state UX içinde görünür olabilir. Conflict ve cache privacy daha fazla önem kazanır. Offline support product feature olarak bilinçli tasarlanmalıdır.

Firebase + Cloud Run Hybrid Architecture

Client Authentication ve Firestore direct access kullanabilir. Complex domain operation Cloud Run backend'e gider. Backend ID token verify eder. Admin SDK veya başka database service kullanabilir. Event-driven integration source of truth sınırını korumalıdır.

Firebase + Generative AI

Generative AI feature kullanıcı prompt ve output data'sı nedeniyle yeni privacy ve abuse riskleri getirir. Firebase Authentication user identity sağlar. App Check supported AI service request abuse'ünü azaltmaya yardımcı olabilir. Model API key client'a konmamalıdır. Rate limit ve content policy backend veya supported service katmanında uygulanmalıdır.

Agentic Applications İçin Firebase

Agentic uygulamalar kullanıcı adına action yapabileceği için authorization scope daha kritik hale gelir. Agent user'ın yetkisini aşmamalıdır. Privileged credential doğrudan client agent prompt context'ine verilmemelidir. Audit log hangi action'ın hangi user veya agent tarafından tetiklendiğini göstermelidir. Human confirmation high-impact action için gerekli olabilir.

Policy ve Security Testing Otomasyonu

Security Rules permission matrix CI içinde otomatik çalışabilir. Static rule lint broad allow pattern'i bulabilir. Backend authorization e2e tests aynı resource matrix'i kullanabilir. App Check enforcement staging test edilir. Continuous security regression Firebase project büyüdükçe daha değerli hale gelir.

Sıkça Sorulan Sorular

Firebase Entegrasyonları: Gerçek Zamanlı Veri ve Yetkilendirme konusunda en çok sorulan sorular database seçimi, authentication, Security Rules, custom claims ve App Check etrafında toplanır. Kısa cevaplar hızlı karar vermeye yardımcı olabilir, ancak production mimarisinde her cevabın permission matrix, query pattern ve platform gereksinimiyle birlikte değerlendirilmesi gerekir. Firebase direct client access sağladığı için güvenlik frontend ekranından bağımsız server-side Rules üzerinde kurulmalıdır. Backend Admin SDK kullanıldığında bu kez application authorization sorumluluğu server koduna geçer. Aşağıdaki sorular proje tasarım toplantılarında hızlı kontrol listesi olarak kullanılabilir.

Firebase nedir?

Firebase web ve mobil application development için Authentication, Firestore, Realtime Database, Storage, Functions ve App Check gibi yönetilen servisler sunan platformdur. Client SDK bazı backend kaynaklarına doğrudan erişebilir. Security Rules bu direct request'lerin authorization katmanıdır. Privileged operation için backend hâlâ gerekir. Firebase seçimi data model ve ekip ihtiyacına göre yapılmalıdır.

Firebase Realtime Database nedir?

Realtime Database veriyi JSON tree içinde tutan ve bağlı client'lara değişiklikleri düşük gecikmeyle ileten Firebase database servisidir. Presence primitive'leri önemli avantajıdır. Query yeteneği Firestore'a göre daha sınırlıdır. Rules path hierarchy ile sıkı ilişkilidir. Basit realtime state için güçlü seçenektir.

Cloud Firestore nedir?

Cloud Firestore collection ve document tabanlı NoSQL database'dir. Query, realtime listener, index ve offline persistence sunar. Firebase yeni müşterilerin çoğuna Firestore ile başlamayı öneriyor. Security Rules document access ve incoming data'yı kontrol eder. Server SDK Rules bypass behavior'ı ayrıca bilinmelidir. :contentReference[oaicite:58]{index=58}

Realtime Database ile Firestore arasındaki fark nedir?

Realtime Database JSON tree, Firestore collection-document model kullanır. Firestore query yetenekleri daha zengindir. Realtime Database native presence primitive'lerinde güçlüdür. Her ikisi realtime listener sunar. Seçim query, presence, offline, scale ve maliyet ihtiyacına göre yapılmalıdır.

Firebase Authentication nasıl çalışır?

Kullanıcı provider credential ile sign-in olur. Firebase UID, ID token ve refresh token tabanlı session oluşturur. ID token backend'de verify edilebilir. Security Rules auth context'i authorization için kullanır. Login olmak bütün data erişimi anlamına gelmez.

Authentication ile authorization arasındaki fark nedir?

Authentication kullanıcının kim olduğunu doğrular. Authorization kullanıcının hangi resource üzerinde hangi operation'ı yapabileceğini belirler. UID authentication sonucudur. Owner, role veya tenant permission authorization modelidir. İki kavram ayrı test edilmelidir.

Firebase Security Rules nedir?

Security Rules client database ve storage request'lerini server tarafında allow veya deny eden declarative policy katmanıdır. Authentication, resource data ve incoming data kullanılabilir. Rules client UI'dan bağımsızdır. Source control ve emulator tests ile yönetilmelidir. Default deny production için güvenli başlangıçtır.

Kullanıcı sadece kendi verisini nasıl görebilir?

Document path UID ile eşleştirilebilir veya ownerId field kullanılabilir. Rule auth UID ile resource owner bilgisini karşılaştırır. Query aynı ownership constraint'i taşımalıdır. User başka UID request ettiğinde deny almalıdır. Different-user emulator test bunu doğrular.

Firebase custom claims nedir?

Custom claims ID token içine eklenen access-control bilgileridir. Yalnız Admin SDK trusted backend üzerinden set edilmelidir. Role veya premium flag için uygundur. Profile data için kullanılmamalıdır. Yeni claim token refresh sonrasında client'a ulaşır.

Firebase ile admin rolü nasıl oluşturulur?

Trusted backend Admin SDK ile user'a admin custom claim atayabilir. Client kendi claim'ini set edemez. Firestore Rules veya backend authorization verified token claim'i kontrol eder. UI admin button gösterebilir. Gerçek permission server side uygulanır.

Firebase App Check nedir?

App Check request'in beklenen app veya device attestation bağlamından gelmesine yardımcı olan abuse protection katmanıdır. Authentication değildir. Security Rules değildir. Web'de reCAPTCHA Enterprise, Android'de Play Integrity ve Apple'da App Attest gibi provider kullanılabilir. Enforcement öncesi metrics izlenmelidir. :contentReference[oaicite:59]{index=59}

App Check Authentication'ın yerini alır mı?

Hayır, App Check user identity doğrulamaz. Valid App Check token taşıyan request signed-out olabilir. Authentication kullanıcıyı tanımlar. Authorization hangi resource'a erişebileceğini belirler. Üç katman birlikte kullanılabilir.

Firestore realtime listener nasıl çalışır?

Document veya query üzerine listener bağlanır. İlk snapshot mevcut state'i verir. Daha sonra result değiştikçe snapshot event gelir. Offline cache snapshot kaynağını etkileyebilir. Listener artık gerekli değilse unsubscribe edilmelidir.

onSnapshot() nedir?

onSnapshot() Firestore Web SDK realtime listener API'sidir. Document veya query reference alabilir. Data callback ve error callback kullanılabilir. Function unsubscribe reference döndürür. React gibi framework'te lifecycle cleanup yapılmalıdır.

Realtime Database'de presence nasıl yapılır?

/.info/connected connection state'i takip eder. onDisconnect() cleanup operation server'a kaydeder. Her cihaz veya tab ayrı connection child kullanabilir. Last seen server timestamp ile güncellenir. Disconnect operation online state yazılmadan önce register edilmelidir. :contentReference[oaicite:60]{index=60}

onDisconnect() nedir?

onDisconnect() Realtime Database server'ın client bağlantısı koptuğunda uygulayacağı operation'ı önceden tanımlar. Presence child remove veya last seen update için kullanılır. Browser unload event'ten daha güvenilirdir. Rule permission operation'a uygulanır. Reconnect sırasında yeniden register edilmelidir.

Firebase offline çalışır mı?

Firestore ve Realtime Database SDK'ları platforma göre offline özellikler sunar. Firestore Android ve Apple'da persistence varsayılan olarak açık, web'de persistent cache varsayılan değildir. Cached read ve queued write kullanılabilir. Server reconnect olduğunda synchronization gerçekleşir. Sensitive cache shared device riskine göre yönetilmelidir. :contentReference[oaicite:61]{index=61}

Firestore Rules filtreleme yapar mı?

Hayır, Firestore Security Rules query result'u document bazında filtrelemez. Query unauthorized document döndürebilecekse request tamamen reddedilir. Query Rules condition ile uyumlu constraint taşımalıdır. Bu behavior Firebase resmi dokümantasyonunda “rules are not filters” olarak açıklanır. Data model ve authorization birlikte tasarlanmalıdır. :contentReference[oaicite:62]{index=62}

Firebase Admin SDK Security Rules'a uyar mı?

Firestore server client libraries ve Admin SDK Security Rules'u bypass ederek Google credential ve IAM ile çalışır. Bu nedenle backend user authorization'ı ayrıca uygulamalıdır. Client ID token verify edilir. Resource ownership veya tenant membership kontrol edilir. Service account IAM least privilege olmalıdır. :contentReference[oaicite:63]{index=63}

Firebase API key gizli midir?

Firebase servisleri için auto-provisioned API key klasik secret değildir ve client config içinde bulunabilir. Firebase resmi dokümantasyonu authorization'ın Security Rules, IAM ve App Check ile sağlandığını belirtiyor. Key API restrictions ile sınırlandırılmalıdır. Firebase dışı hassas API key aynı public key olarak kullanılmamalıdır. Service account private key ise kesinlikle secret'tır. :contentReference[oaicite:64]{index=64}

Firebase güvenli midir?

Firebase doğru Authentication, Security Rules, App Check, IAM ve backend authorization tasarımıyla güvenli application geliştirmek için güçlü araçlar sağlar. Güvenlik varsayılan test mode veya client UI kontrolüne bırakılırsa ciddi açıklar oluşabilir. Rules source control ve test süreci gerektirir. Admin SDK credential güvenliği ayrıca önemlidir. Platform güvenli olsa bile application policy developer sorumluluğundadır.

Firebase büyük uygulamalar için ölçeklenebilir mi?

Firebase çok yüksek trafik taşıyan application'larda kullanılabilir, ancak query, listener, hot document, bandwidth ve cost tasarımı yine gereklidir. Managed scaling kötü data access pattern'ini ortadan kaldırmaz. Firestore geniş query ve scaling ihtiyaçlarında güçlüdür. Realtime Database bazı workload'larda sharding gerektirebilir. Production load ve cost metricleri sürekli izlenmelidir.

Firebase için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Web için JavaScript veya TypeScript, Flutter için Dart, Android için Kotlin ve Apple platformları için Swift doğal seçeneklerdir. Backend Admin SDK farklı server dillerinde kullanılabilir. Team experience ve deployment requirement belirleyicidir. Security Rules bütün client dillerinden bağımsız aynı access policy'yi uygular.

Firebase mi özel backend mi tercih edilmelidir?

Realtime, mobile-first ve hızlı MVP ihtiyacında Firebase development süresini azaltabilir. Complex domain transaction, özel database requirement veya portability önceliğinde custom backend daha uygun olabilir. Hybrid architecture iki yaklaşımı birleştirebilir. Total engineering cost yalnız cloud faturası değildir. Seçim ADR ile gerekçelendirilmelidir.

Firebase entegrasyonlarında gerçek zamanlı veri senkronizasyonu nasıl sağlanır?

Firestore tarafında document veya query üzerine onSnapshot() listener bağlanabilir, Realtime Database tarafında value veya child event listener kullanılabilir. Client ilk state'i alır ve backend data değiştikçe yeni snapshot veya event üretir. Listener query'si yalnız user'ın gerçekten erişebileceği resource scope'unu dinlemelidir. Offline durumda local cache ve pending write kullanıcıya hızlı state gösterebilir, connection geri geldiğinde backend synchronization gerçekleşir. Realtime tasarımda listener lifecycle ve cost monitoring production kalitesinin önemli parçasıdır.

Firebase Realtime Database ile Cloud Firestore arasındaki farklar nelerdir ve hangisi tercih edilmelidir?

Realtime Database tek JSON tree, Firestore collection ve document modeli kullanır. Firestore daha zengin query ve index yetenekleri sunarken Realtime Database presence için /.info/connected ve onDisconnect() gibi doğal primitive'lere sahiptir. Firebase'in güncel rehberi yeni müşterilerin çoğuna Firestore ile başlamayı öneriyor. Presence veya basit low-latency state Realtime Database için uygun olabilir. Bir uygulamada Firestore business data, Realtime Database presence gibi iki servis birlikte de kullanılabilir. :contentReference[oaicite:65]{index=65}

Firebase Authentication ile kullanıcı kimlik doğrulama ve yetkilendirme nasıl yapılandırılır?

Firebase Authentication önce kullanıcıyı provider üzerinden doğrular ve UID ile ID token üretir. Authorization bundan sonra Security Rules veya backend policy ile resource bazında uygulanır. Firebase Authentication kullanıcı yetkilendirme ve rol yönetimi nasıl yapılır sorusunun güçlü cevabı, global küçük role'ler için custom claims, resource-specific yetkiler için owner veya membership data kullanmaktır. Backend custom claim atamasını Admin SDK ile trusted ortamda yapar. UI role bilgisini gösterebilir, fakat gerçek access server-side policy ile enforce edilmelidir.

Firebase Security Rules kullanılarak kullanıcı bazlı okuma ve yazma izinleri nasıl yönetilir?

User document path UID ile eşleştirilebilir veya resource içindeki immutable ownerId field kullanılabilir. Read rule auth UID ile owner bilgisini karşılaştırır, create rule incoming owner ID'nin current UID'ye eşit olduğunu doğrular ve update sırasında owner field değişikliği engellenir. Firestore query aynı ownership constraint'i taşımalıdır çünkü Rules filtre değildir. Realtime Database'de parent rule cascading behavior nedeniyle broad allow verilmemelidir. Firebase Security Rules ile gerçek zamanlı veri erişimi nasıl güvenli hale getirilir sorusunun temel cevabı default deny, least privilege ve otomatik deny testleridir.

Firebase gerçek zamanlı veri ve yetkilendirme entegrasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Kurumsal Firebase entegrasyonu ve gerçek zamanlı uygulama geliştirme hizmeti ararken yalnız SDK kurulumu değil authorization matrix, Security Rules testleri, App Check, offline cache ve production maliyetlerini birlikte ele alan teknik yaklaşımı değerlendirmek faydalıdır. Firebase entegrasyonu ve backend danışmanlığı yakınımda gibi yerel aramalarda Diyarbakır Yazılım Topluluğu çevresindeki proje ve eğitim çalışmalarını incelemek başlangıç noktası olabilir. Topluluk projeleri için https://www.diyarbakiryazilim.com.tr/projects adresi, topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Firebase backend güvenliğini kurumsal API güvenliğiyle birlikte düşünmek isteyen ekipler https://www.diyarbakiryazilim.com.tr/posts/kurumsal-api-guvenligi-ve-rate-limiting-politikalari içeriğinden de yararlanabilir. Eğitim seçerken Emulator Suite üzerinde gerçek owner, attacker ve admin senaryolarının çalıştırılması teorik sunumdan daha kalıcı fayda sağlar.

Sonuç: Firebase Entegrasyonlarında Gerçek Zamanlı Veri ve Yetkilendirme Nasıl Doğru Tasarlanır?

Firebase Entegrasyonları: Gerçek Zamanlı Veri ve Yetkilendirme yaklaşımında başarının anahtarı, Authentication, authorization, App Check ve privileged backend sorumluluklarını birbirinden doğru ayırmaktır. Firebase gerçek zamanlı veri ve authentication entegrasyonu nasıl yapılır sorusu yalnız onSnapshot() veya login fonksiyonu yazmakla cevaplanamaz; veri modeli, Rules, query, token lifecycle, offline cache ve monitoring birlikte tasarlanmalıdır. Firestore yeni projelerin çoğunda güçlü genel tercih sunarken Realtime Database presence ve basit düşük gecikmeli state senaryolarında önemli değer sağlar. Security Rules source control ve Emulator Suite testleriyle yönetildiğinde direct client access modeli daha güvenli hale gelir, Admin SDK kullanılan backend tarafında ise IAM ve application authorization ayrıca uygulanmalıdır. Firebase tabanlı bir ürün, eğitim veya açık kaynak çalışma planlıyorsanız Diyarbakır Yazılım Topluluğu'nun proje alanına https://www.diyarbakiryazilim.com.tr/projects üzerinden ulaşabilir ve topluluk yapısını https://www.diyarbakiryazilim.com.tr/about adresinden inceleyebilirsiniz.