Yönlendiren ve Yönlendiren Politikası ile ilgili en iyi uygulamalar

Maud Nalpas

Bu sayfada, Referrer-Policy'nizi ayarlama ve gelen isteklerde yönlendireni kullanma ile ilgili en iyi uygulamalardan bazıları açıklanmaktadır.

Özet

• Beklenmedik çapraz kaynak bilgi sızıntısı, web kullanıcılarının gizliliğine zarar verir. Koruyucu bir yönlendirme politikası yardımcı olabilir.
• Yönlendiren politikasını strict-origin-when-cross-origin olarak ayarlayın. Yönlendirenin kullanışlılığını büyük ölçüde korurken çapraz kaynaklar arasında veri sızıntısı riskini azaltır.
• Siteler arası istek sahteciliği (CSRF) koruması için yönlendirenleri kullanmayın. Bunun yerine CSRF jetonları ve ek bir güvenlik katmanı olarak diğer başlıkları kullanın.

Not:

• "Site" ve "kaynak" arasındaki farktan emin değilseniz "Aynı site" ve "aynı kaynak" kavramlarını anlama başlıklı makaleyi inceleyin.
• Orijinal spesifikasyondaki bir yazım hatası nedeniyle Referer başlığında R harfi eksik. JavaScript ve DOM'daki Referrer-Policy başlığı ve referrer doğru yazılmış.

Referer ve Referrer-Policy'ye giriş

HTTP istekleri, isteğin yapıldığı kaynağı veya web sayfası URL'sini belirten isteğe bağlı bir Referer üstbilgisi içerebilir. Referrer-Policy başlığı, Referer başlığında hangi verilerin kullanılabilir hale getirileceğini tanımlar.

Aşağıdaki örnekte, Referer üstbilgisi, isteğin yapıldığı site-one sayfasının tam URL'sini içerir.

Referer üstbilgisi içeren bir HTTP isteği.

Referer üstbilgisi farklı istek türlerinde bulunabilir:

• Kullanıcı bir bağlantıyı tıkladığında gezinme istekleri.
• Alt kaynak istekleri: Tarayıcının bir sayfanın ihtiyaç duyduğu resimleri, iframe'leri, komut dosyalarını ve diğer kaynakları istediği durumlar.

Gezinmeler ve iFrame'ler için bu verilere document.referrer kullanarak JavaScript ile de erişebilirsiniz.

Referer değerlerinden çok şey öğrenebilirsiniz. Örneğin, bir analiz hizmeti, site-two.example adresindeki ziyaretçilerin% 50'sinin social-network.example adresinden geldiğini belirlemek için bu bilgileri kullanabilir. Ancak yol ve sorgu dizesi de dahil olmak üzere tam URL, Referer kaynaklar arasında gönderildiğinde kullanıcı gizliliğini tehlikeye atabilir ve güvenlik riskleri oluşturabilir:

Tam URL'nin kullanılması, kullanıcı gizliliğini ve güvenliğini etkileyebilir.

1 ila 5 numaralı URL'ler özel bilgiler ve bazen hassas veya kişisel veriler içerir. Bunların kaynaklar arasında sessizce sızdırılması, web kullanıcılarının gizliliğini tehlikeye atabilir.

6 numaralı URL, özellik URL'sidir. Bu e-posta, amaçlanan kullanıcı dışında birine ulaşırsa kötü niyetli bir kişi bu kullanıcının hesabının kontrolünü ele geçirebilir.

Sitenizden gelen istekler için hangi yönlendiren verilerinin kullanılabilir olduğunu kısıtlamak amacıyla bir yönlendiren politikası belirleyebilirsiniz.

Hangi politikalar kullanılabilir ve aralarındaki farklar nelerdir?

Sekiz politikadan birini seçebilirsiniz. Politikaya bağlı olarak, Referer üstbilgisinden (ve document.referrer) elde edilen veriler şunlar olabilir:

• Veri yok (Referer üstbilgisi yok)
• Yalnızca kaynak
• Tam URL: kaynak, yol ve sorgu dizesi

Yönlendiren verilerine örnekler.

Bazı politikalar, bağlama göre farklı davranacak şekilde tasarlanmıştır: çapraz kaynak veya aynı kaynak isteği, istek hedefinin kaynak kadar güvenli olup olmadığı ya da her ikisi. Bu, kendi sitenizdeki yönlendirenin zenginliğini korurken kaynaklar arasında veya daha az güvenli kaynaklarla paylaşılan bilgi miktarını sınırlamak için kullanışlıdır.

Aşağıdaki tabloda, yönlendiren politikalarının, yönlendiren üstbilgisinden ve document.referrer öğesinden kullanılabilen URL verilerini nasıl kısıtladığı gösterilmektedir:

Politika kapsamı	Politika adı	Yönlendiren: Veri yok	Yönlendiren: Yalnızca kaynak	Yönlendiren: Tam URL
İstek bağlamını dikkate almıyor	no-referrer	check
	origin		check
	unsafe-url			check
Güvenlik odaklı	strict-origin	HTTPS'den HTTP'ye istek	HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye istek
	no-referrer-when-downgrade	HTTPS'den HTTP'ye istek		HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye istek
Gizlilik odaklı	origin-when-cross-origin		Çapraz kaynak isteği	Aynı kaynaktan istek
	same-origin	Çapraz kaynak isteği		Aynı kaynaktan istek
Gizlilik ve güvenlik odaklı	strict-origin-when-cross-origin	HTTPS'den HTTP'ye istek	HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye çapraz kaynak isteği	Aynı kaynaktan istek

MDN, politikaların ve davranış örneklerinin tam listesini sağlar.

Yönlendiren politikası belirlerken dikkat etmeniz gereken bazı noktalar şunlardır:

• Şemayı (HTTPS ve HTTP) dikkate alan tüm politikalar (strict-origin, no-referrer-when-downgrade ve strict-origin-when-cross-origin), HTTP daha az güvenli olsa bile bir HTTP kaynağından başka bir HTTP kaynağına yapılan istekleri, HTTPS kaynağından başka bir HTTPS kaynağına yapılan isteklerle aynı şekilde ele alır. Bunun nedeni, bu politikalar için önemli olanın güvenlikte düşüş olup olmadığıdır. Yani istek, HTTPS → HTTP isteklerinde olduğu gibi şifrelenmiş bir kaynaktaki verileri şifrelenmemiş bir kaynağa gösterebiliyorsa. HTTP → HTTP isteği tamamen şifrelenmemiş olduğundan sürüm düşürme işlemi yapılmaz.
• Bir istek aynı kaynaklı ise şema (HTTPS veya HTTP) aynıdır. Bu nedenle güvenlik düzeyi düşürülmez.

Tarayıcılardaki varsayılan yönlendiren politikaları

Ekim 2021 itibarıyla

Yönlendiren politikası ayarlanmazsa tarayıcı varsayılan politikasını kullanır.

Tarayıcı	Varsayılan Referrer-Policy / Davranış
Chrome	Varsayılan değer: strict-origin-when-cross-origin.
Firefox	Varsayılan değer: strict-origin-when-cross-origin. Sürüm 93'ten itibaren, Katı İzlemeye Karşı Koruma ve Gizli Tarama kullanıcıları için daha az kısıtlayıcı yönlendiren politikaları no-referrer-when-downgrade, origin-when-cross-origin ve unsafe-url, siteler arası isteklerde yoksayılır. Yani yönlendiren, web sitesinin politikasından bağımsız olarak siteler arası isteklerde her zaman kırpılır.
Edge	Varsayılan değer: strict-origin-when-cross-origin.
Safari	Varsayılan, bazı belirli farklılıklar dışında strict-origin-when-cross-origin ile benzerdir. Ayrıntılar için İzleme Önleme İzlemesini Önleme başlıklı makaleyi inceleyin.

Yönlendiren politikası belirlemeyle ilgili en iyi uygulamalar

Hedef: strict-origin-when-cross-origin(veya daha katı) gibi gizliliği artıran bir politikayı açıkça belirleyin.

Siteniz için yönlendiren politikaları belirlemenin farklı yolları vardır:

• HTTP üstbilgisi olarak
• HTML'nizde
• JavaScript'ten istek bazında

Farklı sayfalar, istekler veya öğeler için farklı politikalar belirleyebilirsiniz.

HTTP üstbilgisi ve meta öğesi sayfa düzeyindedir. Bir öğenin geçerli politikasını belirlemek için öncelik sırası aşağıdaki gibidir:

1. Öğe düzeyinde politika
2. Sayfa düzeyinde politika
3. Tarayıcı varsayılanı

Örnek:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Resim, no-referrer-when-downgrade politikasıyla istenir ve bu sayfadaki diğer tüm alt kaynak istekleri strict-origin-when-cross-origin politikasını izler.

Yönlendiren politikasını nasıl görebilirim?

securityheaders.com, belirli bir sitenin veya sayfanın hangi politikayı kullandığını belirlemek için kullanışlıdır.

Belirli bir istek için kullanılan yönlendiren politikasını görmek için Chrome, Edge veya Firefox'taki geliştirici araçlarını da kullanabilirsiniz. Bu makalenin yazıldığı sırada Safari, Referrer-Policy üstbilgisini göstermiyor ancak gönderilen Referer üstbilgisini gösteriyor.

Bir isteğin seçili olduğu Chrome Geliştirici Araçları'nın Ağ paneli.

Web siteniz için hangi politikayı belirlemelisiniz?

strict-origin-when-cross-origin (veya daha katı) gibi gizliliği artıran bir politikayı açıkça ayarlamanızı önemle tavsiye ederiz.

Neden "açıkça"?

Yönlendiren politikası ayarlamazsanız tarayıcının varsayılan politikası kullanılır. Web siteleri genellikle tarayıcının varsayılan politikasını kullanır. Ancak bu ideal bir yöntem değildir çünkü:

• Farklı tarayıcıların farklı varsayılan politikaları vardır. Bu nedenle, tarayıcı varsayılanlarını kullanırsanız siteniz tarayıcılar arasında öngörülebilir şekilde davranmaz.
• Tarayıcılar, çapraz kaynak istekleri için strict-origin-when-cross-origin gibi daha katı varsayılanlar ve yönlendiren kırpma gibi mekanizmalar kullanmaya başlıyor. Tarayıcı varsayılanları değişmeden önce gizliliği iyileştiren bir politikayı açıkça etkinleştirmek, kontrolü size verir ve testleri uygun gördüğünüz şekilde çalıştırmanıza yardımcı olur.

Neden strict-origin-when-cross-origin (veya daha katı)?

Güvenli, gizliliği artıran ve faydalı bir politikaya ihtiyacınız vardır. "Faydalı" ifadesinin anlamı, yönlendirenden ne istediğinize bağlıdır:

• Güvenli: Web siteniz HTTPS kullanıyorsa (kullanmıyorsa bunu öncelikli hale getirin) web sitenizin URL'lerinin HTTPS olmayan isteklerde sızdırılmasını istemezsiniz. Ağdaki herkes bunları görebileceğinden sızıntılar, kullanıcılarınızı ortadaki adam saldırılarına maruz bırakır. no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer ve strict-origin politikaları bu sorunu çözer.
• Gizliliği iyileştirme: Çapraz kaynak isteği için no-referrer-when-downgrade, tam URL'yi paylaşır. Bu durum gizlilik sorunlarına neden olabilir. strict-origin-when-cross-origin ve strict-origin yalnızca kaynağı paylaşır, no-referrer ise hiçbir şey paylaşmaz. Bu durumda gizliliği artırmak için strict-origin-when-cross-origin, strict-origin ve no-referrer seçeneklerini kullanabilirsiniz.
• Faydalı: no-referrer ve strict-origin, aynı kaynaklı istekler için bile tam URL'yi hiçbir zaman paylaşmaz. Tam URL'ye ihtiyacınız varsa strict-origin-when-cross-origin daha iyi bir seçenektir.

Tüm bunlar, strict-origin-when-cross-origin'nin genellikle mantıklı bir seçim olduğu anlamına gelir.

Örnek: strict-origin-when-cross-origin politikası ayarlama

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Sunucu tarafında (ör. Express'te):

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

strict-origin-when-cross-origin (veya daha katı bir kural) tüm kullanım alanlarınızı karşılamıyorsa ne olur?

Bu durumda kademeli bir yaklaşım benimseyin: Web siteniz için strict-origin-when-cross-origin gibi koruyucu bir politika belirleyin ve gerekirse belirli istekler veya HTML öğeleri için daha esnek bir politika uygulayın.

Örnek: öğe düzeyinde politika

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit, siteler arası istekler için document.referrer veya Referer üstbilgisini sınırlayabilir. Ayrıntıları inceleyin.

Örnek: istek düzeyinde politika

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Başka nelere dikkat etmeniz gerekir?

Politikanız; siz, ekibiniz ve şirketiniz tarafından belirlenen web sitenize ve kullanım alanlarınıza bağlı olmalıdır. Bazı URL'ler tanımlayıcı veya hassas veriler içeriyorsa koruyucu bir politika belirleyin.

Uyarı: Size hassas görünmeyen veriler kullanıcılarınız için hassas olabilir veya kullanıcılarınızın çapraz kaynaklı olarak sessizce sızdırılmasını istemediği ya da beklemediği veriler olabilir.

Gelen istekler için en iyi uygulamalar

Siteniz gelen isteklerin yönlendiren URL'sini kullanıyorsa yapmanız gerekenlerle ilgili bazı yönergeleri aşağıda bulabilirsiniz.

Kullanıcı verilerini koruma

Referer özel, kişisel veya kimlik bilgileri içerebileceğinden, bu bilgileri buna göre ele aldığınızdan emin olun.

Gelen yönlendirenler değişebilir {referer-can-change}

Gelen çapraz kaynak isteklerinden yönlendireni kullanmanın birkaç sınırlaması vardır:

• İstek gönderenin uygulaması üzerinde kontrolünüz yoksa aldığınız Referer başlığı (ve document.referrer) hakkında varsayımlarda bulunamazsınız. İstek gönderen , istediği zaman no-referrer politikasına veya daha genel olarak daha önce kullandığından daha katı bir politikaya geçmeye karar verebilir. Bu, Referer adlı CSS'den eskisinden daha az veri alacağınız anlamına gelir.
• Tarayıcılar varsayılan olarak Referrer-Policy strict-origin-when-cross-origin başlığını daha sık kullanıyor. Bu, gönderen sitenin politikası yoksa gelen çapraz kaynak isteklerde artık tam yönlendiren URL'si yerine yalnızca kaynağı alabileceğiniz anlamına gelir.
• Tarayıcılar, Referer yönetimini değiştirebilir. Örneğin, bazı tarayıcı geliştiricileri, kullanıcı gizliliğini korumak için çapraz kaynak alt kaynak isteklerinde yönlendirenleri her zaman kaynaklara kırpmaya karar verebilir.
• Referer üstbilgisi (ve document.referrer), ihtiyacınız olandan daha fazla veri içerebilir. Örneğin, yalnızca isteğin çapraz kaynak olup olmadığını bilmek istediğinizde tam URL'ye sahip olabilir.

Referer için alternatifler

Aşağıdaki durumlarda alternatifleri değerlendirmeniz gerekebilir:

• Sitenizin önemli bir özelliği, gelen çapraz kaynak isteklerinin yönlendiren URL'sini kullanıyor.
• Siteniz artık çapraz kaynak isteğinde ihtiyaç duyduğu yönlendiren URL'sinin bir kısmını almıyor. Bu durum, istek gönderen taraf politikasını değiştirdiğinde veya politika belirlemediğinde ve tarayıcının varsayılan politikası değiştiğinde (Chrome 85'te olduğu gibi) ortaya çıkar.

Alternatifleri tanımlamak için önce yönlendirenin hangi bölümünü kullandığınızı analiz edin.

Yalnızca kaynağa ihtiyacınız varsa

• Yönlendireni, sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız window.location.origin alternatif bir seçenektir.
• Mümkünse Origin ve Sec-Fetch-Site gibi başlıklar size Origin değerini verir veya isteğin çapraz kaynak olup olmadığını açıklar. Bu, tam olarak ihtiyacınız olan şey olabilir.

URL'nin diğer öğelerine (yol, sorgu parametreleri vb.) ihtiyacınız varsa

• İstek parametreleri, kullanım alanınıza uygun olabilir. Bu sayede, yönlendireni ayrıştırma zahmetinden kurtulursunuz.
• Yönlendireni, sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız window.location.pathname alternatif olarak işe yarayabilir. URL'nin yalnızca yol bölümünü ayıklayıp bağımsız değişken olarak iletir. Böylece, URL parametrelerindeki hassas olabilecek bilgiler iletilmez.

Bu alternatifleri kullanamıyorsanız:

• Sistemlerinizi, istek gönderenin (ör. site-one.example) ihtiyacınız olan bilgileri bir tür yapılandırmada açıkça ayarlamasını bekleyecek şekilde değiştirip değiştiremeyeceğinizi kontrol edin.
  • Artısı: Daha açık, site-one.example kullanıcıları için gizliliği korumaya yönelik, geleceğe daha hazır.
  • Dezavantaj: Sizin veya sisteminizin kullanıcıları için daha fazla iş yükü oluşturabilir.
• İstekleri gönderen sitenin, öğe veya istek başına no-referrer-when-downgrade Referrer-Policy ayarlamayı kabul edip etmeyeceğini kontrol edin.
  • Dezavantajı: site-one.example kullanıcıları için gizliliği korumaya yönelik düzeyi daha düşük olabilir, tüm tarayıcılarda desteklenmeyebilir.

Siteler arası istek sahtekarlığı (CSRF) koruması

İstek gönderen, bir no-referrer politikası ayarlayarak yönlendireni göndermemeye her zaman karar verebilir ve kötü niyetli bir kişi, yönlendireni taklit bile edebilir.

Birincil koruma olarak CSRF jetonları kullanın. Ek koruma için SameSite'ı kullanın ve Referer yerine Origin (POST ve CORS isteklerinde kullanılabilir) ve varsa Sec-Fetch-Site gibi başlıkları kullanın.

Günlüğe kaydetme ve hata ayıklama

Referer içinde bulunabilecek kullanıcıların kişisel veya hassas verilerini koruduğunuzdan emin olun.

Yalnızca kaynağı kullanıyorsanız alternatif olarak Origin üstbilgisini kullanıp kullanamayacağınızı kontrol edin. Bu sayede, yönlendireni ayrıştırmanıza gerek kalmadan hata ayıklama için ihtiyacınız olan bilgileri daha basit bir şekilde elde edebilirsiniz.

Ödemeler

Ödeme sağlayıcılar, güvenlik kontrolleri için gelen isteklerin Referer başlığını kullanabilir.

Örneğin:

• Kullanıcı, online-shop.example/cart/checkout üzerinde Satın al düğmesini tıklar.
• online-shop.example, işlemi yönetmek için payment-provider.example adresine yönlendirir.
• payment-provider.example, bu isteğin Referer değerini satıcılar tarafından ayarlanan izin verilen Referer değerleri listesine göre kontrol eder. Listede eşleşen bir giriş yoksa payment-provider.example isteği reddeder. Eşleşme varsa kullanıcı işleme devam edebilir.

Ödeme akışı güvenlik kontrolleriyle ilgili en iyi uygulamalar

Ödeme sağlayıcı olarak, bazı saldırılara karşı temel bir kontrol olarak Referer kullanabilirsiniz. Ancak Referer başlığı tek başına güvenilir bir kontrol temeli değildir. İstek gönderen site, yasal bir satıcı olsun veya olmasın, Referer bilgilerini ödeme sağlayıcı için kullanılamaz hale getiren bir no-referrer politikası belirleyebilir.

Referer değerine bakmak, ödeme sağlayıcıların no-referrer politikası belirlemeyen acemi saldırganları yakalamasına yardımcı olabilir. İlk kontrol olarak Referer kullanıyorsanız:

• Referer her zaman mevcut olmayabilir. Mevcutsa yalnızca içerebileceği minimum veriye (kaynak) göre kontrol edin.
  • İzin verilen Referer değerlerinin listesini ayarlarken yalnızca kaynağı eklediğinizden ve yol eklemediğinizden emin olun.
  • Örneğin, online-shop.example için izin verilen Referer değerleri online-shop.example/cart/checkout değil, online-shop.example olmalıdır. Hiçbir Referer beklemeyerek veya yalnızca istekte bulunan sitenin kaynağı olan bir Referer değeri bekleyerek satıcının Referrer-Policy hakkında varsayımlarda bulunmaktan kaynaklanabilecek hataları önlersiniz.
• Referer yoksa veya varsa ve temel Referer kaynak kontrolünüz başarılıysa daha güvenilir başka bir doğrulama yöntemine geçebilirsiniz.

Ödemeleri daha güvenilir bir şekilde doğrulamak için istekte bulunanın, benzersiz bir anahtarla birlikte istek parametrelerini karma oluşturma işlemine tabi tutmasına izin verin. Ödeme sağlayıcılar daha sonra sizin tarafınızda aynı karmayı hesaplayabilir ve isteği yalnızca hesaplamanızla eşleşirse kabul edebilir.

Yönlendiren bilgisi politikası olmayan bir HTTP satıcı sitesi, HTTPS ödeme sağlayıcısına yönlendirdiğinde Referer ne olur?

HTTPS ödeme sağlayıcısına gönderilen istekte Referer görünmez. Bunun nedeni, bir web sitesinde politika ayarlanmadığında çoğu tarayıcının varsayılan olarak strict-origin-when-cross-origin veya no-referrer-when-downgrade kullanmasıdır. Chrome'un yeni bir varsayılan politikaya geçmesi bu davranışı değiştirmez.

Not: Web siteniz HTTP kullanıyorsa HTTPS'ye geçiş yapın.

Sonuç

Koruyucu bir yönlendiren politikası, kullanıcılarınıza daha fazla gizlilik sağlamanın mükemmel bir yoludur.

Kullanıcılarınızı korumaya yönelik farklı teknikler hakkında daha fazla bilgi edinmek için Güvenli ve emniyetli koleksiyonumuza göz atın.

Kaynaklar

• "Aynı site" ve "aynı kaynak" kavramlarını anlama
• Yeni bir güvenlik başlığı: Referrer Policy (2017)
• MDN'de Referrer-Policy
• Referer başlığı: MDN'de gizlilik ve güvenlik endişeleri
• Chrome değişikliği: Blink uygulama niyeti
• Chrome değişikliği: Blink'in kullanıma sunma niyeti
• Chrome değişikliği: durum girişi
• Chrome değişikliği: 85 beta blog yayını
• Yönlendiren kırpma GitHub ileti dizisi: Farklı tarayıcıların yaptıkları
• Referrer-Policy Spec

Katkıları ve geri bildirimleri için tüm incelemecilere, özellikle de Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck ve Kayce Basques'e çok teşekkür ederiz.