- Katılım
- 21 May 2023
- Mesajlar
- 528
- Tepki
- 17
- Puan
- 18
Kullanıcılardan biri destek talebinde ekran görüntüsü paylaşıyor: sağ üstteki menüde kendi adı değil, başka birinin adı yazıyor. Sunucu loglarında o kullanıcıya ait tek bir istek bile görünmüyor, çünkü sayfa hiç sunucuya gitmedi; CDN önbelleğinden döndü.
Bu tablonun arkasında çoğu zaman gizemli bir açık değil, tek bir yanlış anlaşılmış başlık duruyor: Vary. Bu yazı, standardın Vary'yi nasıl tanımladığını ve bir CDN'in bu tanımı ne kadar uyguladığını, ikisinin arasındaki boşluğun neden bu sonuca yol açtığını göstererek anlatıyor.
HTTP önbelleklemesini tanımlayan RFC 9111, Vary'yi önbellek anahtarının bir parçası olarak ele alıyor. Belgeye göre bir önbellek, saklı yanıtta Vary başlığı varsa, o Vary değerinin işaret ettiği tüm istek başlıkları orijinal istekle eşleşmediği sürece saklı yanıtı doğrulama yapmadan kullanamaz.
Aynı bölüm iki kenar durumu da netleştiriyor. Bir başlık istekte hiç yoksa, ancak diğer istekte de yoksa eşleşmiş sayılıyor. Ve değeri "*" içeren bir Vary başlığı her zaman eşleşmede başarısız oluyor, yani o yanıt hiçbir zaman yeniden kullanılamıyor.
RFC'nin aynı bölümünde, uygulamada en sık karşılaşılan hata açıkça tarif ediliyor: bazı kaynaklar varsayılan yanıtlarında Vary başlığını yanlışlıkla atlıyor ve bunun sonucunda, daha uygun yanıtlar mevcutken bile o yanıt sonraki istekler için seçiliyor.
Bunu somutlaştırmak kolay. Sunucu, oturum açmış kullanıcıya kişiselleştirilmiş bir sayfa üretiyor ama yanıta ne "Vary: Cookie" ne de kişiselleştirilmiş içeriği paylaşımlı önbellekten uzak tutacak bir yönerge koyuyor. Paylaşımlı önbellek için bu yanıt, aynı adresten gelen herkese verilebilecek sıradan bir sayfa.
Belgenin güvenlik bölümü bu noktaya ayrıca değiniyor: çoğu zaman önbellek işleyişinin yanlış anlaşılmasından kaynaklanan uygulama ve kurulum hataları, özel sanılan hassas bilgilerin önbelleğe alınıp yetkisiz taraflara açılmasına yol açabiliyor.
Kişiselleştirilmiş bir yanıtı korumanın yolu Vary listesini uzatmak değil. RFC 9111'in tanımına göre niteliksiz "private" yanıt yönergesi, paylaşımlı bir önbelleğin yanıtı saklamasını yasaklıyor; yani yanıt tek bir kullanıcı için üretilmiş sayılıyor.
Belge bir uyarı da ekliyor: "private" kelimesinin bu kullanımı yalnız yanıtın nerede saklanabileceğini denetliyor, mesaj içeriğinin gizliliğini garanti etmiyor.
Önbellekten eski ya da yanlış içerik dönmesinin daha yaygın hâlini CDN eski sayfayı gösteriyor teşhis yazımızda ele almıştık; buradaki fark, dönen içeriğin eski değil başkasına ait olması.
Standardın söylediği ile bir CDN'in yaptığı aynı şey olmak zorunda değil. Cloudflare'in Vary belgesi varsayılan davranışı açıkça yazıyor: CDN önbellek anahtarlarını isteğin adresinden ve belirli birkaç başlıktan oluşturuyor. Yani kaynağınızın gönderdiği her Vary başlığı kendiliğinden önbellek anahtarına dahil edilmiyor.
Aynı belge, yapılandırmanın tek başına yetmediğini de not ediyor: bir Cache Rule'da Vary tanımlanmış olması, kaynaktan gelen yanıtta Vary başlığı yoksa hiçbir şeyi değiştirmiyor. Buna karşılık "Vary: *" içeren bir yanıt, yapılandırma ne olursa olsun önbelleği baypas ediyor.
RFC 9111 bu duruma da bir kural koyuyor. Aynı adres için birden fazla saklı yanıt varsa, önbelleğin bunlardan birini seçmesi gerekiyor; başlıkta tercih sıralaması için bilinen bir mekanizma varsa (örneğin Accept ve benzeri başlıklardaki q değerleri) o kullanılabiliyor, yoksa Date başlığına göre en yeni yanıt seçiliyor.
Belge ayrıca, saklı yanıtlardan bir kısmı Vary başlığını hiç içermiyorsa, önbelleğin geçerli bir Vary değeri olan en yeni saklı yanıtı seçmesi gerektiğini söylüyor. Yani tek bir hatalı yanıt bile önbellekte kaldığı sürece, sonraki isteklerin hangi sürümü göreceği tahmin edilebilir olmaktan çıkıyor.
Kişiselleştirilmiş içeriğin hiç önbelleğe girmemesi ile origin yükünü azaltmak arasındaki dengeyi Origin Shield yazımızda başka bir açıdan ele almıştık; iki konuda da ölçüm yapmadan varsayıma güvenmemek gerekiyor.
Genel bir güvenlik gözden geçirmesi yapıyorsanız bu kontrolü web güvenliği hataları ve çözümleri listemize de eklemek mantıklı.
Vary, bir yanıtın hangi istek başlıklarına göre ayrıştırılacağını söyleyen bir eşleşme kuralı; kişiselleştirilmiş içeriği korumanın birincil aracı değil. Standart, Vary'nin atlanmasının yanlış yanıtın seçilmesine yol açtığını ve önbellek işleyişinin yanlış anlaşılmasının hassas bilginin açığa çıkmasına neden olabileceğini yazıyor. Paylaşımlı önbellekten uzak tutulması gereken yanıtlar için doğru yönerge private; CDN tarafında da varsayılan önbellek anahtarının ne içerdiğini kendi belgenizden doğrulamanız gerekiyor.
CDN önbelleğinde başka bir kullanıcının içeriğini gördünüz mü?
Güncelleme: 24 Ağustos 2026.
Bu tablonun arkasında çoğu zaman gizemli bir açık değil, tek bir yanlış anlaşılmış başlık duruyor: Vary. Bu yazı, standardın Vary'yi nasıl tanımladığını ve bir CDN'in bu tanımı ne kadar uyguladığını, ikisinin arasındaki boşluğun neden bu sonuca yol açtığını göstererek anlatıyor.
Standart Vary'yi bir eşleşme şartı olarak tanımlıyor
HTTP önbelleklemesini tanımlayan RFC 9111, Vary'yi önbellek anahtarının bir parçası olarak ele alıyor. Belgeye göre bir önbellek, saklı yanıtta Vary başlığı varsa, o Vary değerinin işaret ettiği tüm istek başlıkları orijinal istekle eşleşmediği sürece saklı yanıtı doğrulama yapmadan kullanamaz.
Aynı bölüm iki kenar durumu da netleştiriyor. Bir başlık istekte hiç yoksa, ancak diğer istekte de yoksa eşleşmiş sayılıyor. Ve değeri "*" içeren bir Vary başlığı her zaman eşleşmede başarısız oluyor, yani o yanıt hiçbir zaman yeniden kullanılamıyor.
Asıl risk: Vary'nin hiç gönderilmemesi
RFC'nin aynı bölümünde, uygulamada en sık karşılaşılan hata açıkça tarif ediliyor: bazı kaynaklar varsayılan yanıtlarında Vary başlığını yanlışlıkla atlıyor ve bunun sonucunda, daha uygun yanıtlar mevcutken bile o yanıt sonraki istekler için seçiliyor.
Bunu somutlaştırmak kolay. Sunucu, oturum açmış kullanıcıya kişiselleştirilmiş bir sayfa üretiyor ama yanıta ne "Vary: Cookie" ne de kişiselleştirilmiş içeriği paylaşımlı önbellekten uzak tutacak bir yönerge koyuyor. Paylaşımlı önbellek için bu yanıt, aynı adresten gelen herkese verilebilecek sıradan bir sayfa.
Belgenin güvenlik bölümü bu noktaya ayrıca değiniyor: çoğu zaman önbellek işleyişinin yanlış anlaşılmasından kaynaklanan uygulama ve kurulum hataları, özel sanılan hassas bilgilerin önbelleğe alınıp yetkisiz taraflara açılmasına yol açabiliyor.
Sık atlanan nokta' Alıntı:
Doğru araç Vary değil, private
Kişiselleştirilmiş bir yanıtı korumanın yolu Vary listesini uzatmak değil. RFC 9111'in tanımına göre niteliksiz "private" yanıt yönergesi, paylaşımlı bir önbelleğin yanıtı saklamasını yasaklıyor; yani yanıt tek bir kullanıcı için üretilmiş sayılıyor.
Belge bir uyarı da ekliyor: "private" kelimesinin bu kullanımı yalnız yanıtın nerede saklanabileceğini denetliyor, mesaj içeriğinin gizliliğini garanti etmiyor.
Önbellekten eski ya da yanlış içerik dönmesinin daha yaygın hâlini CDN eski sayfayı gösteriyor teşhis yazımızda ele almıştık; buradaki fark, dönen içeriğin eski değil başkasına ait olması.
CDN'iniz Vary'yi ne kadar uyguluyor?
Standardın söylediği ile bir CDN'in yaptığı aynı şey olmak zorunda değil. Cloudflare'in Vary belgesi varsayılan davranışı açıkça yazıyor: CDN önbellek anahtarlarını isteğin adresinden ve belirli birkaç başlıktan oluşturuyor. Yani kaynağınızın gönderdiği her Vary başlığı kendiliğinden önbellek anahtarına dahil edilmiyor.
Aynı belge, yapılandırmanın tek başına yetmediğini de not ediyor: bir Cache Rule'da Vary tanımlanmış olması, kaynaktan gelen yanıtta Vary başlığı yoksa hiçbir şeyi değiştirmiyor. Buna karşılık "Vary: *" içeren bir yanıt, yapılandırma ne olursa olsun önbelleği baypas ediyor.
Birden fazla sürüm saklandığında ne oluyor?
RFC 9111 bu duruma da bir kural koyuyor. Aynı adres için birden fazla saklı yanıt varsa, önbelleğin bunlardan birini seçmesi gerekiyor; başlıkta tercih sıralaması için bilinen bir mekanizma varsa (örneğin Accept ve benzeri başlıklardaki q değerleri) o kullanılabiliyor, yoksa Date başlığına göre en yeni yanıt seçiliyor.
Belge ayrıca, saklı yanıtlardan bir kısmı Vary başlığını hiç içermiyorsa, önbelleğin geçerli bir Vary değeri olan en yeni saklı yanıtı seçmesi gerektiğini söylüyor. Yani tek bir hatalı yanıt bile önbellekte kaldığı sürece, sonraki isteklerin hangi sürümü göreceği tahmin edilebilir olmaktan çıkıyor.
Kendi kurulumunuzda nasıl sınarsınız
- İki farklı oturum açın: Aynı adresi iki ayrı tarayıcı profilinden, biri oturum açık biri kapalı olacak şekilde isteyin.
- Yanıt başlıklarını karşılaştırın: Kişiselleştirilmiş yanıtta Cache-Control ne diyor, private var mı, Vary hangi başlıkları sayıyor?
- Önbellek durumunu okuyun: CDN'inizin durum başlığı ikinci istekte HIT diyorsa, o içerik paylaşımlı önbellekte duruyor demektir.
- Kişiselleştirilmiş uçları ayırın: Sepet, panel ve profil gibi uçlar için yanıtın paylaşımlı önbellekte saklanmadığından emin olun.
Kişiselleştirilmiş içeriğin hiç önbelleğe girmemesi ile origin yükünü azaltmak arasındaki dengeyi Origin Shield yazımızda başka bir açıdan ele almıştık; iki konuda da ölçüm yapmadan varsayıma güvenmemek gerekiyor.
Genel bir güvenlik gözden geçirmesi yapıyorsanız bu kontrolü web güvenliği hataları ve çözümleri listemize de eklemek mantıklı.
Özetle
Vary, bir yanıtın hangi istek başlıklarına göre ayrıştırılacağını söyleyen bir eşleşme kuralı; kişiselleştirilmiş içeriği korumanın birincil aracı değil. Standart, Vary'nin atlanmasının yanlış yanıtın seçilmesine yol açtığını ve önbellek işleyişinin yanlış anlaşılmasının hassas bilginin açığa çıkmasına neden olabileceğini yazıyor. Paylaşımlı önbellekten uzak tutulması gereken yanıtlar için doğru yönerge private; CDN tarafında da varsayılan önbellek anahtarının ne içerdiğini kendi belgenizden doğrulamanız gerekiyor.
CDN önbelleğinde başka bir kullanıcının içeriğini gördünüz mü?
Güncelleme: 24 Ağustos 2026.
Dijital Dünyanıza Yön Veren Pusula
Ekli dosyalar
Son düzenleme:
