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

Bu sayfada, Referrer-Policy'nizi ayarlama ve gelen isteklerde yönlendireni kullanma konusunda bazı en iyi uygulamalar özetlenmektedir.

Özet

• Beklenmeyen merkezler arası bilgi sızıntısı, web kullanıcılarının gizliliğine zarar veriyor. Koruyucu bir yönlendiren politikası yardımcı olabilir.
• strict-origin-when-cross-origin yönlendiren politikası belirleyebilirsiniz. Yönlendirenin kullanışlılığının büyük bir kısmını korurken kaynaklar arasında veri sızıntısı riskini azaltır.
• Siteler Arası İstek Sahtekarlığı (CSRF) koruması için yönlendirenler kullanmayın. Bunun yerine CSRF jetonları ve ek bir güvenlik katmanı olarak diğer başlıkları kullanın.

Yönlendiren ve Yönlendiren Politikası 101

HTTP istekleri, isteğin yapıldığı kaynak veya web sayfası URL'sini belirten isteğe bağlı bir Referer üst bilgisi içerebilir. Referrer-Policy üst bilgisi, Referer üst bilgisinde hangi verilerin kullanıma sunulacağını tanımlar.

Aşağıdaki örnekte Referer başlığı, site-one sitesindeki isteğin yapıldığı sayfanın tam URL'sini içerir.

Referer başlığı farklı istek türlerinde olabilir:

• Kullanıcı bir bağlantıyı tıkladığında gezinme istekleri.
• Bir tarayıcı bir sayfanın ihtiyaç duyduğu resimler, iframe'ler, komut dosyaları ve diğer kaynakları istediğinde alt kaynak istekleri.

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 sitesindeki ziyaretçilerin% 50'sinin social-network.example konumundan geldiğini belirlemek için bunları kullanabilir. Ancak yol ve sorgu dizesi dahil tam URL, kaynaklar genelinde Referer içinde gönderildiğinde kullanıcı gizliliğini tehlikeye atabilir ve güvenlik riskleri oluşturabilir:

1'den 5'e kadar olan URL'ler özel bilgiler ve bazen de hassas veya tanımlayıcı bilgiler içeriyor. Bunları sessizce belirli bir kaynaktan sızdırmak web kullanıcılarının gizliliğini tehlikeye atabilir.

6. URL bir özellik URL'sidir. Bu e-posta, hedeflenen kullanıcı dışında bir kişi tarafından kullanılırsa kötü amaçlı 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ıma sunulacağını kısıtlamak için bir yönlendiren politikası ayarlayabilirsiniz.

Hangi politikalar kullanılabilir ve nasıl farklılık gösterir?

Sekiz politikadan birini seçebilirsiniz. Politikaya bağlı olarak Referer başlığından (ve document.referrer) kullanılabilen veriler aşağıdaki gibi olabilir:

• Veri yok (Referer başlığı yok)
• Yalnızca origin
• Tam URL: kaynak, yol ve sorgu dizesi

Bazı politikalar, bağlama şartlarına (kaynaklar arası veya aynı kaynak isteği, istek hedefinin kaynak kadar güvenli olup olmadığı veya her ikisi) bağlı olarak farklı şekilde davranacak şekilde tasarlanmıştır. Bu, kendi sitenizdeki yönlendirenin zenginliğini korurken, kaynaklar arasında paylaşılan bilgi miktarını veya güvenliği daha düşük kaynaklarla sınırlandırmak için yararlı olur.

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

Politika kapsamı	Politika adı	Başvuran: Veri yok	Yönlendiren: Yalnızca kaynak	Yönlendiren: Tam URL
İsteğin bağlamı dikkate alınmaz	no-referrer	çek
	origin		çek
	unsafe-url			çek
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		Kaynaklar arası istek	Aynı kaynak isteği
	same-origin	Kaynaklar arası istek		Aynı kaynak isteği
Gizlilik ve güvenlik odaklı	strict-origin-when-cross-origin	HTTPS'den HTTP'ye istek	Çapraz kaynak isteği HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye	Aynı kaynak isteği

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

Bir yönlendiren politikası belirlerken göz önünde bulundurmanız gereken bazı noktalar şunlardır:

• Şemayı (HTTPS - HTTP) dikkate alan tüm politikalar (strict-origin, no-referrer-when-downgrade ve strict-origin-when-cross-origin), bir HTTP kaynağından başka bir HTTP kaynağına yapılan istekleri, HTTP daha az güvenli olsa bile bir 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, güvenlikte eski sürüme geçişin yapılıp yapılmadığıdır. Diğer bir deyişle, isteğin şifrelenmiş bir kaynaktan gelen verileri, HTTPS → HTTP isteklerinde olduğu gibi şifrelenmemiş bir kaynağa ifşa edip edemeyeceğidir. HTTP → HTTP isteği tamamen şifrelenmemiş olduğu için eski sürüme geçilemez.
• Bir isteğin same-origin olması, şemanın (HTTPS veya HTTP) aynı olduğu anlamına gelir. Bu şekilde güvenlik düzeyi düşürülmez.

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

Ekim 2021 itibarıyla

Bir yönlendiren politikası belirlenmemişse tarayıcı varsayılan politikasını kullanır.

Yönlendiren politikası belirlemek için en iyi uygulamalar

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

• HTTP başlığı olarak
• HTML
• JavaScript'ten istek bazında

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

Hem HTTP üstbilgisi hem de meta öğesi sayfa düzeyindedir. Bir öğenin etkili politikasını belirlemek için öncelik sırası şu şekildedir:

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" />

Görüntü, no-referrer-when-downgrade politikasıyla istenir ve bu sayfadaki diğer tüm alt kaynak istekleri strict-origin-when-cross-origin politikasına uyar.

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 üzere Chrome, Edge veya Firefox'taki geliştirici araçlarını da kullanabilirsiniz. Bu yazının yazıldığı sırada Safari, Referrer-Policy üst bilgisini göstermez ancak gönderilen Referer bilgisini göstermektedir.

Web siteniz için hangi politikayı belirlemelisiniz?

strict-origin-when-cross-origin gibi (veya daha katı) bir gizlilik artırıcı politika belirlemenizi kesinlikle öneririz.

Neden "açıkça"?

Bir yönlendiren politikası belirlemezseniz tarayıcının varsayılan politikası kullanılır. Hatta, web siteleri genellikle tarayıcının varsayılan politikasını tercih eder. Ancak bu ideal bir seçenek değildir, çünkü:

• Farklı tarayıcıların farklı varsayılan politikaları vardır. Bu nedenle, tarayıcı varsayılan ayarlarını kullanırsanız siteniz tüm tarayıcılarda tahmin edilebilir şekilde çalışmaz.
• Tarayıcılar, strict-origin-when-cross-origin gibi daha katı varsayılan ayarları ve kaynaklar arası istekler için yönlendiren kırpma gibi mekanizmaları kullanmaktadır. Tarayıcı varsayılanları değişmeden önce bir gizliliği iyileştiren politikayı açıkça etkinleştirmek, kontrol sahibi olmanızı sağlar ve uygun gördüğünüz şekilde testler yapmanıza yardımcı olur.

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

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

• Güvenli: Web siteniz HTTPS kullanıyorsa (kullanılmıyorsa öncelikli hale getirin), web sitenizin URL'lerinin HTTPS olmayan isteklerde sızmasını istemezsiniz. Ağdaki herkes bunları görebildiğinden, sızıntılar kullanıcılarınızı ortadaki kişi 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 çözmektedir.
• Gizliliği artıran: Kaynaklar arası istekler 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ıran seçenekler olarak strict-origin-when-cross-origin, strict-origin ve no-referrer sunulur.
• Yararlı: no-referrer ve strict-origin, aynı kaynak istekleri 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'in genellikle mantıklı bir seçim olduğu anlamına gelir.

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

index.html:

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

Veya sunucu tarafında, örneğin Express'te:

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

strict-origin-when-cross-origin (veya daha katı) seçeneği tüm kullanım alanlarınıza uymuyorsa ne olur?

Bu durumda progresif bir yaklaşım kullanın: Web siteniz için strict-origin-when-cross-origin gibi koruyucu bir politika ve gerekirse belirli istekler ya da HTML öğeleri için daha geniş kapsamlı bir politika belirleyin.

Ö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 üst bilgisini sınırlandırabilir. Ayrıntıları inceleyin.

Örnek: istek düzeyinde politika

script.js:

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

Başka neleri göz önünde bulundurmalısınız?

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

Gelen istekler için en iyi uygulamalar

Siteniz gelen isteklerin yönlendiren URL'sini kullanıyorsa ne yapmanız gerektiğiyle ilgili bazı yönergeler aşağıda verilmiştir.

Kullanıcı verilerini koruyun

Referer gizli, kişisel veya tanımlayıcı veriler içerebilir. Bu nedenle, bu verileri uygun şekilde kullandığınızdan emin olun.

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

Gelen çapraz kaynak isteklerinden yönlendireni kullanmayla ilgili birkaç sınırlama vardır:

• İstek ileticinin uygulaması üzerinde kontrolünüz yoksa aldığınız Referer başlığı (ve document.referrer) hakkında varsayımlarda bulunamazsınız. İstek iletici, istediği zaman bir no-referrer politikasına veya daha genel olarak, önceden kullandığından daha katı bir politikaya geçmeye karar verebilir. Bu, Referer ürününden geçmişe kıyasla daha az veri alacağınız anlamına gelir.
• Tarayıcılar, varsayılan olarak Referrer-Policy strict-origin-when-cross-origin'yi giderek daha fazla kullanmaktadır. Bu, gönderen sitede hiçbir politika ayarlanmamışsa gelen çapraz kaynak isteklerinde artık tam yönlendiren URL'si yerine yalnızca kaynağı alabileceğiniz anlamına gelir.
• Tarayıcılar Referer sayfasını yönetme biçimlerini değiştirebilir. Örneğin, bazı tarayıcı geliştiricileri, kullanıcı gizliliğini korumak için çapraz kaynak alt kaynakları isteklerinde yönlendirenleri her zaman yalnızca kaynağa yönlendirmeye karar verebilir.
• Referer başlığı (ve document.referrer) ihtiyacınız olandan daha fazla veri içerebilir. Örneğin, isteğin çapraz kaynak olup olmadığını öğrenmek istiyorsanız tam URL'si olabilir.

Referer alternatifleri

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

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

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

Yalnızca kaynak kaynağına 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 çözümdür.
• Varsa Origin ve Sec-Fetch-Site gibi başlıklar, size Origin bilgisini verir veya isteğin çapraz kaynak olup olmadığını açıklar. Bu, tam olarak ihtiyaç duyduğunuz şey olabilir.

URL'nin başka öğelerine (yol, sorgu parametreleri...) ihtiyacınız varsa

• İstek parametreleri kullanım alanınıza uygun olabilir. Bu da sizi yönlendireni ayrıştırma zahmetinden kurtarır.
• Yönlendireni sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız, window.location.pathname alternatif olarak çalışabilir. URL'nin yalnızca yol bölümünü çıkarıp bağımsız değişken olarak aktarın. Böylece URL parametrelerindeki hassas olabilecek bilgiler aktarılmaz.

Bu alternatifleri kullanamıyorsanız:

• Sistemlerinizi, istek ileticinin (örneğin, site-one.example) bir tür yapılandırmada ihtiyaç duyduğunuz bilgileri açıkça ayarlamasını bekleyecek şekilde değiştirip değiştiremeyeceğinizi kontrol edin.
  • Avantajı: site-one.example kullanıcıları için daha anlaşılır, gizliliği daha fazla korur ve geleceğe daha iyi uyum sağlar.
  • Dezavantajı: Potansiyel olarak sizin tarafınızdan veya sistem kullanıcılarının daha fazla iş yükü olur.
• İstekleri gönderen sitenin, no-referrer-when-downgrade için öğe başına veya istek başına bir Yönlendirme Politikası ayarlamayı kabul edip edemeyeceğini kontrol edin.
  • Dezavantaj: site-one.example kullanıcıları için gizliliği daha az koruyabilir ve tüm tarayıcılarda desteklenmeyebilir.

Siteler Arası İstek Sahtekarlığı (CSRF) koruması

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

Birincil korumanız olarak CSRF jetonları kullanın. Daha fazla 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ük ve hata ayıklama

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

Yalnızca kaynağı kullanıyorsanız alternatif olarak Origin üst bilgisini kullanıp kullanamayacağınızı kontrol edin. Bu, hata ayıklama amacıyla ihtiyacınız olan bilgileri daha basit bir şekilde ve yönlendireni ayrıştırmanıza gerek kalmadan verebilir.

Ö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 ürününde Satın al düğmesini tıklar.
• online-shop.example, işlemi yönetmek için payment-provider.example öğesine yönlendirir.
• payment-provider.example, bu isteğin Referer değerini, satıcılar tarafından ayarlanan izin verilen Referer değerleri listesiyle karşılaştırarak kontrol eder. Listedeki hiçbir girişle eşleşmezse payment-provider.example isteği reddeder. Eşleşirse kullanıcı işleme devam edebilir.

Ödeme akışı güvenlik kontrolleri için en iyi uygulamalar

Ödeme sağlayıcı olarak Referer hizmetini bazı saldırılara karşı temel bir kontrol olarak kullanabilirsiniz. Bununla birlikte, Referer üst bilgisi tek başına kontrol için güvenilir bir temel değildir. İstekte bulunan site, yasal bir satıcı olsun veya olmasın, Referer bilgilerini ödeme sağlayıcının kullanımına engelleyen bir no-referrer politikası belirleyebilir.

Referer incelemek, ödeme sağlayıcıların no-referrer politikası belirlememiş naif saldırganları yakalamasına yardımcı olabilir. İlk kontrol olarak Referer kullanırsanız:

• Referer öğesinin her zaman mevcut olmasını beklemeyin. Dosya varsa yalnızca içerebileceği minimum verilerle, yani kaynakla karşılaştırarak kontrol edin.
  • İzin verilen Referer değerlerinin listesini ayarlarken yalnızca kaynağı dahil ettiğ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ç Referer olmaması veya yalnızca istekte bulunan sitenin kaynağı olan bir Referer değeri bekleyerek, satıcının Referrer-Policy hakkında varsayımlarda bulunmaktan oluşabilecek hataları engellersiniz.
• 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 kişinin, benzersiz bir anahtarla istek parametrelerini karma hale getirmesine izin verin. Daha sonra ödeme sağlayıcıları, aynı karmayı kendi tarafınızda hesaplayabilir ve isteği yalnızca hesaplamanızla eşleşiyorsa kabul edebilir.

Yönlendiren politikası olmayan bir HTTP satıcı sitesi bir HTTPS ödeme sağlayıcıya yönlendirirse Referer öğesine ne olur?

Bir web sitesinde bir politika ayarlanmamışsa çoğu tarayıcı varsayılan olarak strict-origin-when-cross-origin veya no-referrer-when-downgrade kullandığından HTTPS ödeme sağlayıcıya gönderilen istekte Referer görünmez. Chrome'un yeni bir varsayılan politikaya geçmesi bu davranışı değiştirmez.

Sonuç

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

Kullanıcılarınızı korumak amacıyla kullanılan farklı teknikler hakkında daha fazla bilgi edinmek için Güvenli ve güvenli koleksiyonumuza göz atın.

Kaynaklar

• "Aynı site" ve "aynı-kaynak"ı anlama
• Yeni bir güvenlik başlığı: Yönlendiren Politikası (2017)
• MDN'deki Yönlendiren Politikası
• Yönlendiren başlığı: MDN'de gizlilik ve güvenlikle ilgili endişeler
• Chrome değişikliği: Uygulamak için niyeti göz ardı etmeyin
• Chrome değişikliği: Kargonuzu gönderme isteğini göz önünde bulundurun
• Chrome değişikliği: Durum girişi
• Chrome değişikliği: 85 beta blog yayını
• Yönlendiren GitHub iş parçacığını kırpma: farklı tarayıcılar ne yapar?
• Yönlendiren Politikası Spesifikasyonu

Başta Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck ve Kayce Basques olmak üzere tüm yorumculara katkıları ve geri bildirimleri için çok teşekkür ederiz.