Önce kimin, neye erişeceğini tarif edin
Bir not uygulaması düşünelim. Kullanıcı giriş yapıyor, birkaç fikir kaydediyor ve sonra başka bir cihazdan devam ediyor. İlk bakışta basit bir akış. Peki ikinci bir kullanıcı, başka bir notun adresini öğrendiğinde ne olacak? Güvenlik tasarımı tam da bu soruyla başlar. Ekranda yalnızca ilgili notları göstermek, veriye erişimi tek başına sınırlamaz.
Firebase Authentication kimlik doğrulama işini üstlenir. Cloud Firestore Security Rules ise mobil ve web istemcilerinden gelen veri isteklerinin hangi koşullarda kabul edileceğini belirler. Giriş yapan herkese bütün belgeleri açmak, özel notlar için uygun bir kural değildir. Önce ‘kullanıcı yalnızca kendisine ait notları okuyabilir ve düzenleyebilir’ gibi açık bir ürün kararı yazın.
Bu örnekte paylaşım yok. İleride ortak not eklenirse yeni üyeler, davetler ve erişim kaldırma davranışı ayrıca tasarlanmalı. Henüz ihtiyaç duyulmayan bir paylaşım modelini ilk sürüme taşımak yerine, başlangıçtaki sınırı anlaşılır tutmak işleri kolaylaştırır.
Veri modelini bu sınırla birlikte kurun
Özel notları kullanıcıya ait bir yol altında tutmayı seçebilirsiniz: users/{uid}/notes/{noteId}. Yolun içindeki kullanıcı kimliği ile istekteki doğrulanmış kimliğin eşleşmesini kontrol eden bir kural, bu örnek için anlaşılır bir başlangıçtır. Belge kimliğini tahmin etmenin zor olması erişim kontrolünün yerini tutmaz; sınırı kurallar uygular.
Yazma yetkisi verirken verinin şeklini de düşünün. Başlık gerçekten metin mi, beklenen uzunlukta mı, istemci yalnızca izin verilen alanları mı gönderiyor? Firestore kuralları alan ve tür kontrollerine izin verir. Kullanıcının değiştirebildiği bir profil alanını yönetici yetkisinin dayanağı yapmak gibi dolaylı açıkları da gözden geçirin.
Küçük bir veri sözlüğü hazırlamak faydalıdır: Her alan ne anlatıyor, kim oluşturuyor, sonradan kim değiştirebiliyor? Böylece arayüzde yapılan bir değişikliğin kuralları etkileyip etkilemediği daha kolay görülür. Örneğin notlara renk eklemek sıradan bir ekran işi gibi görünse de kabul edilen alanlar listesinde karşılığı olmalıdır.
Sorguyu da erişim modeline göre tasarlayın
Firestore kuralları sonuçları sonradan süzen bir filtre değildir. İzin verilmeyen belgeleri de döndürebilecek bir sorgu bütünüyle reddedilebilir. Tüm notları isteyip arayüzde kullanıcıya göre ayırmak yerine, sorguyu erişim sınırını karşılayacak biçimde kurun. Kullanıcı alt koleksiyonu örneğinde listeyi doğrudan ilgili kullanıcının notlarından okumak bu ilişkiyi açık tutar.
Liste ekranının gerçekten kaç kayda ihtiyacı olduğunu da belirleyin. İlk görünümde sınırlı bir sonuç kümesi, daha fazlası için sayfalama ve anlaşılır bir boş durum genellikle iyi bir başlangıçtır. ‘Veri gelmedi’ ile ‘erişim reddedildi’ durumlarını aynı mesajla geçmeyin. Kullanıcıya yeniden giriş önerirken geliştiricinin hatalı bir kuralı fark etmesini zorlaştırmayın.
İzin verilen kadar, reddedilen yolu da deneyin
Firebase Local Emulator Suite ile kuralları yerelde sınayabilirsiniz. Kuralları test ortamına açıkça yükleyin; ardından farklı kimliklerle istekler oluşturun. JavaScript tarafındaki rules-unit-testing paketi bu senaryoları otomatikleştirmeye yardımcı olur. Üretim verisi yerine küçük, bilinen örneklerle ilerlemek, testin hangi davranışı ölçtüğünü görmeyi kolaylaştırır.
Bir tabloya beklenen sonucu yazın ve her kural değişikliğinde aynı senaryoları çalıştırın. Özellikle reddedilmesi gereken işlemler önemlidir: Başarılı bir kayıt ekranı, başka bir hesabın notunun korunduğunu göstermez. Test verisini senaryolar arasında temizleyin; önceki denemenin bıraktığı kayıtlar yanlış bir güven duygusu oluşturmasın.
- Giriş yapmayan biri özel notu okuyamamalı.
- Bir kullanıcı kendi notunu oluşturup düzenleyebilmeli.
- Aynı kullanıcı başka bir hesaba ait notu okuyamamalı veya değiştirememeli.
- Beklenmeyen alanlar ve geçersiz veri türleri reddedilmeli.
App Check ek bir katman, sunucu ise ayrı bir sınır
App Check, uygulama veya cihaz doğrulamasıyla desteklenen servislere gelen isteklerin kötüye kullanımını azaltmaya yardımcı olur. Kullanıcının hangi nota erişebileceğine karar vermez; Authentication ve kuralların yerini almaz. Tüm kötüye kullanım biçimlerini engelleme garantisi de vermez. Bu araçları, aynı sorunu çözen alternatifler yerine farklı sorumlulukları olan katmanlar olarak düşünün.
Sunucu tarafında Admin SDK veya Firestore sunucu kitaplıkları kullanıldığında Security Rules uygulanmaz; erişimde IAM yetkileri devreye girer. Dolayısıyla sunucudaki bir uç nokta, gelen kullanıcının ilgili işlemi yapmaya yetkili olduğunu ayrıca doğrulamalıdır. Not silme gibi basit bir işlemde bile istekle gelen kimliğe körü körüne güvenmeyin.
İlk sürüm için küçük bir kontrol listesi yeterli olabilir: Veri sınırı belli mi, reddedilen istekler sınandı mı, arayüz hata durumlarını açıklıyor mu? Yeni özellik geldiğinde bu sorulara dönün. Güvenli başlangıç, her şeyi tek seferde bitirmekten çok, değişiklikleri kontrol edilebilir adımlarla ilerletmektir.
Kaynaklar ve devamı
Konuyu biraz daha kurcalamak istersen, bu yazıda yararlandığımız resmî dokümanlar burada.