Çerez domain ve path alanları nasıl sınırlandırılmalıdır?

Çerezleri mümkün olan en dar kapsamda oluşturun: yalnızca gerçekten ihtiyaç duyan host için Domain alanını hiç göndermeyin; zorunlu bir alt alan adı paylaşımı varsa en üst ortak alanı değil, gereken en dar alanı seçin. Path değerini de çerezin kullanıldığı uygulama diziniyle sınırlandırın. Ancak Path bir güvenlik sınırı değildir; aynı host üzerindeki başka bir uygulama uygun koşullarda çerezi etkileyebilir veya isteklere eklenmesini gözlemleyebilir. Hassas oturum çerezlerinde host-only kapsam, HTTPS ve uygun çerez öznitelikleri birlikte kullanılmalıdır.

Domain alanı nasıl seçilir?​

Domain belirtilmezse çerez host-only olur. Örneğin panel.example.com yanıtı Domain göndermeden bir çerez oluşturursa bu çerez example.com veya api.example.com isteklerine gönderilmez; yalnızca panel.example.com için geçerlidir. Bu, oturum çerezleri için genellikle en güvenli başlangıçtır.

Domain=example.com kullanıldığında çerez, alan adının alt alan adlarına da gönderilebilir. Bu yalnızca uygulamanın gerçekten panel.example.com, api.example.com ve benzeri hostlar arasında aynı çereze ihtiyaç duyduğu durumda seçilmelidir. Domain=.example.com yazımı ayrıca gerekli değildir; alan adı çerezlerinde baştaki nokta anlamlı bir ek kapsam sağlamaz.

Bir çerez, istemci tarafından sunulan alan adını genişletmek için kullanılamaz. Örneğin app.example.com yanıtı, ilgisiz bir another-example.com alanı için çerez tanımlayamaz. Ana alan adını tüm alt alanlara açmak, alt alanlardan biri ele geçirildiğinde veya güvensiz bir uygulama çalıştırdığında ortak çerezlerin riskini artırır.

Path alanı nasıl seçilir?​

Path, çerezin hangi URL yollarındaki isteklere ekleneceğini belirler. Uygulama yalnızca /admin/ altında çalışıyorsa Path=/admin/ seçilebilir. Sitenin tamamında gereken bir oturum çerezi için Path=/ kullanılır. /admin ile /admin/ arasında uygulamanın kullandığı URL biçimine göre fark olabileceğinden, gerçek istek yollarıyla uyumlu değer seçilmelidir.

Path değeri erişimi tamamen güvenli biçimde izole etmez. Aynı host üzerinde çalışan başka bir yol, tarayıcının çerezi o yola göndermediği durumlarda bile güvenlik sınırı olarak kabul edilmemelidir. Bu nedenle yönetim uygulamasını ayrı bir hosta almak, yalnızca Path kısıtlamasına güvenmekten daha güçlü bir ayrımdır.

Örneğin panel.example.com üzerinde yalnızca yönetim uygulaması varsa aşağıdaki tercih dar kapsamlıdır:


Burada Domain yoktur; çerez yalnızca panel.example.com hostuna aittir. Yönetim uygulaması aynı hostta /admin/ altında çalışıyorsa Path=/admin/ denenebilir. Fakat uygulamanın giriş, çıkış veya API istekleri /auth/ gibi başka yollardaysa bunlar da kapsam dışında kalır ve oturum beklenmedik biçimde çalışmaz.

Pratik seçim tablosu​

Aşağıdaki karar, kapsamı gereksiz yere büyütmemek için kullanılabilir.


Tablodaki ortak alan seçeneğini yalnızca paylaşım teknik olarak zorunluysa kullanın. Özellikle oturum veya yönetim çerezlerinde, Domain eklemek yerine uygulamaları aynı host üzerinde gerekli ortak yolları kullanacak şekilde tasarlamak daha dar bir kapsam sağlayabilir.

Uygulama ve kontrol adımları​

1. Çerezi kullanan gerçek hostları ve URL yollarını listeleyin. Her çerecin hangi istekte okunması gerektiğini belirlemeden ortak bir Domain veya Path seçmeyin.
2. Paylaşım gerekmiyorsa Domain özniteliğini kaldırın. Paylaşım gerekiyorsa yalnızca ihtiyaç duyan alt hostları kapsayan en dar alanı seçin.
3. Path değerini gerekli en dar uygulama yoluna ayarlayın; fakat giriş, yenileme, çıkış ve API uçlarının bu kapsamda kaldığını kontrol edin.
4. Oturum çerezlerinde Secure ve HttpOnly kullanın. Çapraz site davranışı gerekiyorsa SameSite seçimini uygulamanın giriş akışına göre belirleyin; Path bu özniteliklerin yerine geçmez.
5. Tarayıcı geliştirici araçlarında çerezin host, path ve gönderildiği istekleri kontrol edin. Beklenmeyen alt hostlara gidiyorsa Domain fazla geniştir; gerekli isteklere gitmiyorsa Path fazla dardır.
6. Kapsam değişikliğinden sonra eski geniş kapsamlı çerezi de temizleyin. Silme yanıtında, eski çerezin oluşturulurken kullanılan Domain ve Path değerleriyle eşleşen bir silme çerezi gönderin.

Host-only oturum çerezlerinde ek bir savunma olarak __Host- öneki kullanılabilir. Bu adlandırma kuralı, çerezin Secure olmasını, Path=/ kullanmasını ve Domain içermemesini gerektirir; koşullar sağlanmıyorsa tarayıcı çerezi kabul etmez. Ancak bu yaklaşım, aynı hosttaki güvenilmeyen uygulamalar sorununu çözmez ve sunucu tarafındaki yetkilendirme kontrollerinin yerini tutmaz.

Sık yapılan hatalar​

En yaygın hata, tüm alt alanlarda kullanılmayacak bir çereze Domain=example.com vermektir. İkinci hata, /admin/ değerini tam bir güvenlik duvarı sanmaktır. Üçüncü hata ise yeni dar kapsamlı çerezi oluştururken eski geniş kapsamlı aynı adlı çerezi silmemektir; bu durumda tarayıcı birden fazla çerez gönderebilir ve sunucu beklenmeyen değeri seçebilir. Aynı adın farklı Path değerleriyle kullanılmasından kaçının veya geçiş sırasında tüm eski kapsamları açıkça temizleyin.

Kaynaklar​

• MDN: Set-Cookie öznitelikleri
• RFC 6265: HTTP çerez kapsamı

Sık sorulan sorular​

Bir çerezde Domain alanını boş bırakmakla hiç göndermemek aynı mıdır?​

Güvenli ve öngörülebilir tercih, Domain özniteliğini yanıt başlığına hiç eklememektir. Boş bir değer framework veya tarayıcı tarafından farklı ele alınabileceğinden buna güvenilmemelidir.

Path=/admin/ çerezi /admin sayfasına gönderilir mi?​

Hayır. Path=/admin/, /admin/ ve alt yollarıyla eşleşir; sondaki eğik çizginin olmadığı /admin isteğiyle eşleşmez. Path=/admin ise /admin, /admin/ ve alt yollarıyla eşleşir, /administrator ile eşleşmez. Sunucunun yönlendirmesi sonraki isteğin yolunu değiştirebilir; tarayıcının her isteğe eklediği çerezi ayrı kontrol edin.

Domain ve Path sunucu tarafında yetkilendirme yerine geçer mi?​

Hayır. Bunlar çerezin hangi isteklere eklenmesini sınırlar; kullanıcı yetkisini doğrulamak için sunucu tarafında oturum, rol ve kaynak kontrolleri ayrıca yapılmalıdır.