Güvenlik Kuralları'nın işleyiş şekli

Cloud Firestore

Temel yapı

Cloud Firestore ve Cloud Storage içindeki Firebase Security Rules, aşağıdaki yapıyı ve söz dizimini kullanır:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Kuralları oluştururken aşağıdaki temel kavramları anlamanız önemlidir:

• İstek: allow ifadesi içinde çağrılan yöntem veya yöntemler. Bunlar, çalıştırılmasına izin verdiğiniz yöntemlerdir. Standart yöntemler şunlardır: get, list, create, update ve delete. read ve write kolaylık yöntemleri, belirtilen veritabanında veya depolama yolunda geniş kapsamlı okuma ve yazma erişimi sağlar.
• Yol: URI yolu olarak temsil edilen veritabanı veya depolama konumu.
• Kural: Doğru olarak değerlendirilirse bir isteğe izin veren bir koşul içeren allow ifadesi.

Güvenlik kuralları 2. sürüm

Mayıs 2019 itibarıyla Firebase güvenlik kurallarının 2. sürümü kullanıma sunuldu. Kuralların 2. sürümünde, yinelenen joker karakterlerin {name=**} davranışı değiştirildi. Koleksiyon grubu sorgularını kullanmayı planlıyorsanız 2. sürümü kullanmanız gerekir. Güvenlik kurallarınızdaki ilk satırı rules_version = '2'; yaparak 2. sürümü etkinleştirmeniz gerekir:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

Eşleşen yollar

Tüm eşleşme ifadeleri koleksiyonlara değil, dokümanlara işaret etmelidir. Eşleşme ifadesi, match /cities/SF'te olduğu gibi belirli bir dokümanı işaretleyebilir veya match /cities/{city}'te olduğu gibi belirtilen yoldaki herhangi bir dokümanı işaretlemek için joker karakterler kullanabilir.

Yukarıdaki örnekte, eşleme ifadesi {city} joker karakter söz dizimini kullanır. Bu, kuralın cities koleksiyonundaki tüm dokümanlar (ör. /cities/SF veya /cities/NYC) için geçerli olduğu anlamına gelir. Eşleme ifadesindeki allow ifadeleri değerlendirildiğinde city değişkeni, SF veya NYC gibi şehir dokümanı adına çözümlenir.

Eşleşen alt koleksiyonlar

Cloud Firestore'teki veriler, belge koleksiyonları halinde düzenlenir ve her belge, alt koleksiyonlar aracılığıyla hiyerarşiyi genişletebilir. Güvenlik kurallarının hiyerarşik verilerle nasıl etkileşime girdiğini anlamak önemlidir.

cities koleksiyonundaki her dokümanın bir landmarks alt koleksiyonu içerdiğini varsayalım. Güvenlik kuralları yalnızca eşleşen yolda geçerli olduğundan cities koleksiyonunda tanımlanan erişim denetimleri landmarks alt koleksiyonunda geçerli değildir. Bunun yerine, alt koleksiyonlara erişimi kontrol etmek için açık kurallar yazın:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

      // Explicitly define rules for the 'landmarks' subcollection
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

match ifadeleri iç içe yerleştirilirken iç match ifadesinin yolu her zaman dış match ifadesinin yoluna göredir. Bu nedenle aşağıdaki kural kümeleri eşdeğerdir:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

Yinelemeli joker karakterler

Kuralların, keyfi olarak derin bir hiyerarşiye uygulanmasını istiyorsanız yinelenen joker karakter söz dizimini ({name=**}) kullanın:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

Yinelenen joker karakter söz dizimi kullanıldığında, joker karakter değişkeni, doküman derinlemesine iç içe yerleştirilmiş bir alt koleksiyonda yer alsa bile eşleşen yol segmentinin tamamını içerir. Örneğin, yukarıda listelenen kurallar /cities/SF/landmarks/coit_tower konumunda bulunan bir belgeyle eşleşecek ve document değişkeninin değeri SF/landmarks/coit_tower olacaktır.

Ancak yinelenen joker karakterlerin davranışının kurallar sürümüne bağlı olduğunu unutmayın.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

Koleksiyon grubu sorguları kullanıyorsanız 2. sürümü kullanmanız gerekir. Koleksiyon grubu sorgularının güvenliğini sağlama başlıklı makaleyi inceleyin.

Çakışan eşleşme ifadeleri

Bir belgenin birden fazla match ifadesiyle eşleşmesi mümkündür. Birden fazla allow ifadesinin bir istekle eşleştiği durumlarda, aşağıdaki koşullardan truebiri geçerliyse erişime izin verilir:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

Yukarıdaki örnekte, ilk kural her zaman false olsa bile ikinci kural her zaman true olduğu için cities koleksiyonuna yapılan tüm okuma ve yazma işlemlerine izin verilir.

Güvenlik kuralı sınırları

Güvenlik kurallarıyla çalışırken aşağıdaki sınırlara dikkat edin:

Cloud Storage

Temel yapı

Cloud Firestore ve Cloud Storage içindeki Firebase Security Rules, aşağıdaki yapıyı ve söz dizimini kullanır:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Kuralları oluştururken aşağıdaki temel kavramları anlamanız önemlidir:

• İstek: allow ifadesi içinde çağrılan yöntem veya yöntemler. Bunlar, çalıştırılmasına izin verdiğiniz yöntemlerdir. Standart yöntemler şunlardır: get, list, create, update ve delete. read ve write kolaylık yöntemleri, belirtilen veritabanında veya depolama yolunda geniş kapsamlı okuma ve yazma erişimi sağlar.
• Yol: URI yolu olarak temsil edilen veritabanı veya depolama konumu.
• Kural: Doğru olarak değerlendirilirse bir isteğe izin veren bir koşul içeren allow ifadesi.

Eşleşen yollar

Cloud Storage Security Rules match Cloud Storage içindeki dosyalara erişmek için kullanılan dosya yolları. Kurallar match tam yollar veya joker karakterli yollar olabilir ve kurallar iç içe yerleştirilebilir. Hiçbir eşleşme kuralı bir istek yöntemine izin vermiyorsa veya koşul false olarak değerlendiriliyorsa istek reddedilir.

Tam eşlemeler

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

İç içe yerleştirilmiş eşleşmeler

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

Joker karakter eşleşmeleri

Kurallar, joker karakterler kullanarak bir kalıbı match etmek için de kullanılabilir. Joker karakter, profilePhoto.png gibi tek bir dizeyi veya images/profilePhoto.png gibi birden fazla yol segmentini temsil eden adlandırılmış bir değişkendir.

Joker karakter, joker karakter adının etrafına köşeli parantez ekleyerek oluşturulur (ör. {string}). Joker karakter adına =** ekleyerek birden fazla segment joker karakteri belirtilebilir (ör. {path=**}):

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Birden fazla kural bir dosyayla eşleşirse sonuç, tüm kural değerlendirmelerinin sonucunun OR'sidir. Yani, dosyanın eşleştiği bir kural true olarak değerlendirilirse sonuç true olur.

Yukarıdaki kurallarda, condition veya other_condition doğru olarak değerlendirilirse "images/profilePhoto.png" dosyası okunabilir. "images/users/user:12345/profilePhoto.png" dosyası ise yalnızca other_condition sonucuna tabidir.

Joker değişkenine, match dosya adı veya yol yetkilendirmesi içinden referans verilebilir:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Cloud Storage Security Rules basamaklandırılmaz ve kurallar yalnızca istek yolu, belirtilen kurallara sahip bir yola eşleştiğinde değerlendirilir.

Değerlendirme isteğinde bulunma

Yüklemeler, indirmeler, meta veri değişiklikleri ve silme işlemleri, Cloud Storage adresine gönderilen request kullanılarak değerlendirilir. request değişkeni, isteğin gerçekleştirildiği dosya yolunu, isteğin alındığı zamanı ve istek bir yazma işlemiyse yeni resource değerini içerir. HTTP üstbilgileri ve kimlik doğrulama durumu da dahildir.

request nesnesi, kullanıcının benzersiz kimliğini ve request.auth nesnesinde Firebase Authentication yükü de içerir. Bu konu, dokümanların Kimlik Doğrulaması bölümünde daha ayrıntılı olarak açıklanmaktadır.

request nesnesinde bulunan özelliklerin tam listesini aşağıda bulabilirsiniz:

Kaynak değerlendirmesi

Kuralları değerlendirirken yüklenen, indirilen, değiştirilen veya silinen dosyanın meta verilerini de değerlendirmek isteyebilirsiniz. Bu sayede, yalnızca belirli içerik türlerine sahip dosyaların yüklenmesine veya yalnızca belirli bir boyuttan büyük dosyaların silinmesine izin verme gibi işlemleri yapan karmaşık ve güçlü kurallar oluşturabilirsiniz.

Cloud Storage için Firebase Security Rules, resource nesnesinde dosya meta verilerini sağlar. Bu nesne, Cloud Storage nesnesinde gösterilen meta verilerin anahtar/değer çiftlerini içerir. Bu özellikler, veri bütünlüğünü sağlamak için read veya write isteklerinde denetlenebilmektedir.

write isteklerinde (yükleme, meta veri güncelleme ve silme gibi), istek yolunda mevcut olan dosyanın meta verilerini içeren resource nesnesine ek olarak, yazma işlemine izin verilirse yazılacak dosya meta verilerinin bir alt kümesini içeren request.resource nesnesini de kullanabilirsiniz. Veri bütünlüğünü sağlamak veya dosya türü ya da boyut gibi uygulama kısıtlamalarını uygulamak için bu iki değeri kullanabilirsiniz.

resource nesnesinde bulunan özelliklerin tam listesini aşağıda bulabilirsiniz:

request.resource, generation, metageneration, etag, timeCreated ve updated hariç bunların tümünü içerir.

Güvenlik Kuralları sınırları

Güvenlik kurallarıyla çalışırken aşağıdaki sınırlara dikkat edin:

Tam Örnek

Tüm bunları bir araya getirerek bir resim depolama çözümü için kuralların tam bir örneğini oluşturabilirsiniz:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

Realtime Database

Temel yapı

Realtime Database içinde Firebase Security Rules, JSON belgesinde bulunan JavaScript benzeri ifadelerden oluşur.

Şu söz dizimini kullanırlar:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Kural üç temel öğeden oluşur:

• Yol: Veritabanı konumu. Bu, veritabanınızın JSON yapısını yansıtır.
• İstek: Kuralın erişim izni vermek için kullandığı yöntemlerdir. read ve write kuralları geniş kapsamlı okuma ve yazma erişimi sağlarken validate kuralları, gelen veya mevcut verilere göre erişim izni vermek için ikincil bir doğrulama görevi görür.
• Durum: Doğru olarak değerlendirilirse isteğe izin veren durum.

Kurallar yollara nasıl uygulanır?

Realtime Database'te Rules atomik olarak uygulanır. Yani daha üst düzey üst öğe düğümlerindeki kurallar, daha ayrıntılı alt öğe düğümlerindeki kuralları geçersiz kılar ve daha derin bir düğümdeki kurallar bir üst öğe yoluna erişim izni veremez. Üst yollardan birine erişim izni verdiyseniz veritabanı yapınızdaki daha derin bir yolda erişim iznini ayrıntılandıramaz veya iptal edemezsiniz.

Aşağıdaki kuralları göz önünde bulundurun:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

Bu güvenlik yapısı, /foo/ değeri true olan bir baz alt öğesi içerdiğinde /bar/ öğesinin okunmasına olanak tanır. Erişim, alt yol tarafından iptal edilemediğinden /foo/bar/ altındaki ".read": false kuralı burada geçerli değildir.

Bu, ilk bakışta sezgisel görünmese de kurallar dilinin güçlü bir parçasıdır ve çok karmaşık erişim ayrıcalıklarının minimum çabayla uygulanmasına olanak tanır. Bu, özellikle kullanıcıya dayalı güvenlik için yararlıdır.

Ancak .validate kuralları basamaklandırılmaz. Yazma işlemine izin verilmesi için tüm doğrulama kurallarının hiyerarşinin tüm seviyelerinde karşılanması gerekir.

Ayrıca, kurallar üst bir yola geri uygulanmadığından, istenen konumda veya üst konumda erişim izni veren bir kural yoksa okuma veya yazma işlemi başarısız olur. Etkilenen her alt yola erişilebilse bile üst konumda okuma işlemi tamamen başarısız olur. Şu yapıyı düşünün:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

Kuralların atomik olarak değerlendirildiğini anlamadan, /records/ yolunun getirilmesi sonucunda rec1 değerinin döndürüleceği, rec2 değerinin ise döndürülmeyeceği düşünülebilir. Ancak gerçek sonuç bir hatadır:

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];

var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});

curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

/records/ adresindeki okuma işlemi atomik olduğundan ve /records/ altındaki tüm verilere erişim izni veren bir okuma kuralı olmadığından bu işlem PERMISSION_DENIED hatası oluşturur. Bu kuralı Firebase konsolumuzdaki güvenlik simülatöründe değerlendirirsek okuma işleminin reddedildiğini görebiliriz:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

Hiçbir okuma kuralı /records/ yoluna erişime izin vermediği için işlem reddedildi. Ancak, isteğimizdeki yolda olmadığı için rec1 kuralının hiçbir zaman değerlendirilmediğini unutmayın. rec1 değerini almak için doğrudan bu değere erişmemiz gerekir:

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Konum değişkeni

Realtime Database Rules, yol segmentlerini eşleştirmek için $location değişkenini destekler. Kuralınızı yol boyuncaki herhangi bir alt düğümle eşleştirmek için yol segmentinizin önüne $ ön ekini ekleyin.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

Sabit yol adlarıyla paralel olarak $variable simgesini de kullanabilirsiniz.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }