Referer

Referer başlığı (evet, yanlış yazılmış — 1996 HTTP spesifikasyonu kanonik formu “Referer” olarak belirledi ve yazım hatası standart hâle geldi) çoğu istekte tarayıcılar tarafından gönderilir; kullanıcının isteği tetiklediği andaki sayfanın URL’sini içerir.

Kullanım alanları:

• Web analitiği — “bu trafik nereden geldi?”
• Sıcak bağlantı önleme — resim sunucularının isteklerin onaylı sitelerden geldiğini doğrulaması.
• CSRF savunması (derinlemesine) — bazı uygulamalar Referer’ın beklenen origin ile eşleşip eşleşmediğini doğrular.
• Bağlı kuruluş atfı — hangi ortak sitenin dönüşüm sağladığını izleme.

Modern gizlilik endişesi: URL yolu içindeki token’lar, arama sorguları veya kişisel tanımlanabilir bilgiler dahil olmak üzere tam URL, sayfanın yüklediği her üçüncü taraf kaynağa sızar. Referrer-Policy yanıt başlığı (bu kez doğru yazılmış biçimiyle) tarayıcıların ne kadar referrer bilgisi göndereceğini denetler:

• no-referrer: hiçbir zaman Referer başlığı gönderme.
• same-origin: aynı origin isteklere tam URL gönder, diğerlerine hiçbir şey.
• strict-origin-when-cross-origin: çapraz origin HTTPS isteklerine yalnızca origin gönder. Modern tarayıcı varsayılanı.
• unsafe-url: her zaman tam URL gönder. Kaçının.

Gizlilik açısından hassas uygulamalar için her yanıtta katı bir politika belirleyin.

Ünlü yazım hatası: başlık ilk kez 1995’te Phillip Hallam-Baker tarafından önerildi; spesifikasyon, hata fark edilmeden önce “Referrer” yerine “Referer” yazdı. Birisi fark ettiğinde birkaç büyük uygulama zaten yayındaydı. RFC 1945, yazım hatasını kanonik olarak dondurdu ve o tarihten beri her tarayıcı HTTP hat uyumluluğu için yanlış formu kullanmak zorunda kaldı. W3C 2014’te bir politika başlığı eklediğinde, onu eski istek başlığından ayırt etmek için kasıtlı olarak doğru yazdı (Referrer-Policy).

Modern tarayıcıların varsayılan olarak gönderdiği: Chrome 85 (Ağu 2020), Firefox 87 (Mar 2021) ve Safari 14 itibarıyla varsayılan politika strict-origin-when-cross-origin’dir. Çapraz origin istekler artık yalnızca origin’i (https://example.com) alır, tam URL’yi değil. Aynı origin istekler hâlâ tam URL’yi alır. Bu tek değişiklik, on yıllık kazara URL-token sızıntılarını üçüncü taraf analitik ve reklam teknolojisi scriptlerine karşı ortadan kaldırdı. Maksimum paranoya gerektiren kurulumlar (bankacılık, sağlık) için her yanıta Referrer-Policy: no-referrer ayarlayın. Kaynak: W3C — Referrer Policy.

Çalışma örneği: şifre sıfırlama URL’si sızıntısı

Yaygın bir ihlal örüntüsü: bir uygulama, https://app.example.com/reset?token=abc123def456... biçiminde şifre sıfırlama bağlantısı içeren e-posta gönderir. Kullanıcı tıklar; sıfırlama sayfası yüklenir ve Google Analytics, Facebook Pixel ile bir CDN’den bir grafik kütüphanesi içerir. 2020 öncesi varsayılan politika altında her üçüncü taraf isteği Referer: https://app.example.com/reset?token=abc123def456... bilgisini taşır ve sıfırlama token’ı dört farklı satıcının sunucu günlüğüne sızardı. Modern strict-origin-when-cross-origin varsayılanı altında çapraz origin istekler yalnızca Referer: https://app.example.com taşır ve token gizli kalır. Daha da iyisi, her hassas akış yanıtına Referrer-Policy: no-referrer ayarlayın — derinlemesine savunmanın maliyeti sıfırdır.

Politikaya rağmen hâlâ sızan bilgiler

Referrer-Policy yalnızca Referer başlığını yönetir. URL token’ları tarayıcı geçmişinde, aynı origin scriptleri tarafından görülebilen document.referrer JavaScript özelliğinde, window.location günlük ifadelerinde ve URL’leri yakalayan her hata izleme SDK’sında görünmeye devam eder. Mimari çözüm, hassas token’ları istek gövdesine veya açılışta hemen ayarlanan kısa ömürlü bir çereze taşımak, ardından token içermeyen bir URL’ye yönlendirmektir. Kaynak: RFC 9110 — HTTP Semantics §10.1.3 (Referer); 2022 HTTP yeniden yazımında orijinal yazım hatası korunmuştur.