Referer

Der Referer-Header (ja, falsch geschrieben – die HTTP-Spezifikation von 1996 legte die kanonische Form als “Referer” fest, und der Tippfehler wurde zum Standard) wird von Browsern bei den meisten Requests gesendet und enthält die URL der Seite, auf der sich der Nutzer befand, als er den Request auslöste.

Verwendet für:

• Web-Analytics — “woher stammt dieser Traffic?”
• Hotlink-Schutz — Bildhoster, die prüfen, ob Requests von genehmigten Seiten stammen.
• CSRF-Defence-in-Depth — manche Anwendungen prüfen, ob der Referer mit dem erwarteten Origin übereinstimmt.
• Affiliate-Attribution — Nachverfolgung, welche Partnerseite eine Conversion ausgelöst hat.

Modernes Datenschutzproblem: die vollständige URL – einschließlich aller Tokens, Suchanfragen oder personenbezogener Daten im URL-Pfad – gelangt an jede Drittanbieter-Ressource, die die Seite lädt. Der Referrer-Policy-Response-Header (Hinweis: diesmal korrekt geschrieben) steuert, wie viele Referrer-Informationen Browser senden:

• no-referrer: niemals einen Referer-Header senden.
• same-origin: vollständige URL an Same-Origin-Requests senden, nichts an andere.
• strict-origin-when-cross-origin: nur den Origin an Cross-Origin-HTTPS-Requests senden. Standard moderner Browser.
• unsafe-url: immer die vollständige URL senden. Vermeiden.

Setzen Sie für datenschutzsensible Anwendungen bei jeder Response eine strikte Policy.

Der berühmte Tippfehler: der Header wurde 1995 ursprünglich von Phillip Hallam-Baker vorgeschlagen, und die Spezifikation verschrieb “Referrer” als “Referer”, bevor der Fehler bemerkt wurde. Als es jemandem auffiel, hatten mehrere große Implementierungen ihn bereits ausgeliefert. RFC 1945 schrieb den Schreibfehler als kanonisch fest, und jeder Browser seither muss die falsche Form für die HTTP-Kompatibilität auf Protokollebene verwenden. Als das W3C 2014 einen Policy-Header hinzufügte, schrieb es ihn bewusst korrekt (Referrer-Policy), um ihn vom alten Request-Header zu unterscheiden.

Was moderne Browser standardmäßig senden: seit Chrome 85 (Aug. 2020), Firefox 87 (März 2021) und Safari 14 lautet die Standard-Policy strict-origin-when-cross-origin. Cross-Origin-Requests erhalten nun nur noch den Origin (https://example.com), nicht die vollständige URL. Same-Origin-Requests erhalten weiterhin die vollständige URL. Diese eine Änderung beseitigte ein Jahrzehnt versehentlicher URL-Token-Lecks an Drittanbieter-Analytics- und Ad-Tech-Skripte. Für Setups mit maximaler Vorsicht (Banking, Gesundheitswesen) setzen Sie Referrer-Policy: no-referrer bei jeder Response – die Produktions-Header von Convertitive verwenden standardmäßig strict-origin-when-cross-origin. Referenz: W3C — Referrer Policy.

Durchgerechnetes Beispiel: ein Passwort-Reset-URL-Leck

Ein häufiges Sicherheitsleck-Muster: eine Anwendung versendet per E-Mail einen Passwort-Reset-Link der Form https://app.example.com/reset?token=abc123def456.... Der Nutzer klickt; die Reset-Seite lädt und bindet Google Analytics, Facebook Pixel und eine Charting-Bibliothek von einem CDN ein. Unter der Standard-Policy vor 2020 trug jeder Drittanbieter-Request Referer: https://app.example.com/reset?token=abc123def456... – wodurch der Reset-Token in die Server-Logs von vier verschiedenen Anbietern gelangte. Unter dem modernen Standard strict-origin-when-cross-origin tragen die Cross-Origin-Requests nur Referer: https://app.example.com, und der Token bleibt privat. Noch besser: setzen Sie Referrer-Policy: no-referrer bei jeder Response in sensiblen Abläufen – Defence in Depth kostet nichts.

Was trotz Policy weiterhin durchsickert

Referrer-Policy steuert nur den Referer-Header. URL-Tokens erscheinen weiterhin im Browserverlauf, in der für Same-Origin-Skripte sichtbaren JavaScript-Eigenschaft document.referrer, in window.location-Log-Anweisungen und in jedem Error-Monitoring-SDK, das URLs erfasst. Die architektonische Lösung besteht darin, sensible Tokens in den Request-Body oder in ein kurzlebiges Cookie zu legen, das unmittelbar beim Aufruf gesetzt wird, und dann auf eine URL ohne den Token weiterzuleiten. Referenz: RFC 9110 — HTTP Semantics §10.1.3 (Referer), das den ursprünglichen Schreibfehler in der kanonischen HTTP-Neufassung von 2022 beibehält.