Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 6 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi
Secure niteliği bulunan bir çerez yalnızca güvenli bağlantı üzerinden, yani HTTPS ile yapılan isteklere eklenir. Kullanıcı sitenizi HTTP üzerinden açtığında tarayıcı bu çerezi isteğe koymaz. Böylece oturum kimliği gibi hassas bir değerin şifrelenmemiş HTTP trafiğinde gönderilmesi önlenir. Ancak Secure tek başına çerezi şifrelemez, JavaScript erişimini engellemez ve siteler arası istekleri kontrol etmez.

Örneğin sunucu şu yanıtı döndürsün:

Kod:
Set-Cookie: session_id=ORNEK_DEGER; Path=/; Secure; HttpOnly; SameSite=Lax

Kullanıcı https://example.com/account adresine gittiğinde çerez gönderilebilir. Aynı kullanıcı http://example.com/account adresine giderse session_id isteğe eklenmez. HTTPS bağlantısının şifreleme ve kimlik doğrulama görevini TLS, çerezin HTTPS dışına çıkmamasını ise Secure niteliği sağlar.

Diğer çerez nitelikleriyle farkı​


Secure, çerezin taşıma koşulunu belirler. Diğer güvenlik nitelikleri farklı sorunları çözer:

NitelikNe kontrol eder?Tek başına neyi çözmez?
SecureÇerezin yalnızca HTTPS üzerinden gönderilmesiniJavaScript erişimini veya CSRF isteklerini
HttpOnlyÇereğin document.cookie gibi istemci API’leriyle okunması/değiştirilmesiniÇerezin HTTP üzerinden gönderilmesini
SameSiteÇerezlerin siteler arası isteklerde gönderilme davranışınıHTTPS kullanımını veya XSS açıklarını
Domain ve PathÇerezin hangi alan adı ve URL yollarında gönderileceğiniBağlantının HTTPS olup olmadığını

Oturum çerezlerinde çoğunlukla Secure ile birlikte HttpOnly ve uygulamanın ihtiyacına uygun SameSite değeri değerlendirilir. Çereğin tarayıcıdaki JavaScript tarafından okunması gerçekten gerekmiyorsa HttpOnly eklemek, Secure’ın tamamlayıcısıdır.

Uygulama ve kontrol adımları​


  1. Üretim ortamındaki uygulamayı HTTPS üzerinden çalıştırın ve HTTP isteklerini HTTPS’e yönlendirin. Uygulama yönlendirme işleminden önce oturum çerezi üretmemelidir.
  2. Oturum veya kimlik doğrulama çerezinin sunucu tarafından oluşturulduğu noktaya Secure niteliğini ekleyin. Örnek biçim Set-Cookie: session_id=DEGER; Secure şeklindedir.
  3. Çerezin JavaScript tarafından okunmasına gerek yoksa HttpOnly, siteler arası istek davranışı için de uygun SameSite değerini ekleyin.
  4. Tarayıcı geliştirici araçlarında ilgili çerezin Secure sütununu kontrol edin. HTTPS isteğinde gönderildiğini, HTTP isteğinde gönderilmediğini doğrulayın.
  5. HTTP’den HTTPS’e geçişten sonra oturumun kaybolduğunu görürseniz uygulamanın çerezi yalnız HTTPS isteğinde üretip üretmediğini ve ters vekil sunucunun HTTPS bilgisini uygulamaya doğru aktarıp aktarmadığını inceleyin.

Başarı ölçütü, çerezin HTTPS isteğinde görünmesi ve HTTP isteğinin Cookie başlığında görünmemesidir. HTTPS isteğinde de gönderilmiyorsa alan adı, Path, süresi dolma zamanı veya tarayıcının çerezi engelleme gerekçesi kontrol edilmelidir. HTTP isteğinde gönderiliyorsa çerez gerçekten Secure olarak oluşturulmamış olabilir; eski ve yeni çerez kayıtlarının adlarını ve kapsamlarını karşılaştırın.

Üretimde HTTP kökeninden Secure cookie koymaya çalışmak tarayıcı tarafından reddedilebilir. HSTS, sonraki bağlantıların HTTPS’e yükseltilmesine yardımcı olur; Secure ise cookie gönderim koşuludur. Aynı adla farklı Domain/Path çerezleri birlikte bulunabileceğinden yalnız Cookie başlığında ada bakmak yeterli değildir. Örnekteki değer gerçek oturum sırrı değil yer tutucudur; sunucu güçlü ve tahmin edilemez kimlik üretmelidir. Path bir yetki sınırı değildir.

Sık yapılan hatalar​


Secure’ı şifreleme sanmak: Secure yalnızca gönderim kuralıdır. Çerez değeri HTTPS ile taşınırken TLS tarafından korunur; uygulama günlüklerine veya istemci depolamasına açık biçimde yazılması Secure tarafından engellenmez.

Yalnızca giriş çerezini korumak: Girişten sonra kullanılan ayrı bir yetkilendirme veya yenileme çerezi varsa onun niteliği de ayrıca incelenmelidir. En zayıf bırakılan hassas çerez risk oluşturur.

HTTP’yi tamamen yok saymak: Kullanıcı HTTP adresine girdiğinde Secure çerez gönderilmeyeceği için uygulama onu oturumsuz görebilir. Kalıcı çözüm, kullanıcıyı HTTPS’e yönlendirmek ve uygulamanın güvenli bağlantıyı doğru algılamasını sağlamaktır.

Secure ile HttpOnly’yi karıştırmak: Secure, ağ üzerindeki HTTP gönderimini sınırlar; HttpOnly ise JavaScript erişimini sınırlar. Birinin eklenmesi diğerinin yerine geçmez.

Kaynaklar​



Sık sorulan sorular​


Secure çerez HTTP sayfasında okunabilir mi?​

Normal HTTP kökeninde Secure çerez gönderilmez ve document.cookie erişiminde de güvenli bağlam koşulları uygulanır. HTTPS sayfasında HttpOnly yoksa JavaScript erişimi mümkün olabilir; Secure, HttpOnly yerine geçmez. Tarayıcılar localhost geliştirme ortamına özel istisnalar uygulayabilir; bunu üretim HTTP davranışı diye genellemeyin.

Secure çerez alt alan adlarına da gönderilir mi?​

Bu, Secure’dan değil Domain ve Path kapsamından etkilenir. Çerez alt alan adlarını kapsayacak şekilde tanımlanmışsa ve istek HTTPS ise eşleşen alt alan adına gönderilebilir. Yalnızca belirli ana makineye ait olması istenen çerezlerde kapsamı gereksiz genişletmeyin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic