Referrer-Policy im Detail: Schutz vor Datenlecks

Während der HTTP-Header Referrer-Policy das generelle Browser-Verhalten steuert, befasst sich diese Seite mit dem Sicherheitsaspekt: dem Schutz vor unbeabsichtigten Datenabflüssen (sogenannten Referrer Leaks). Viele Webanwendungen übermitteln unbewusst vertrauliche Daten (wie E-Mail-Adressen, Session-IDs, Passwörter oder persönliche Profile) über URL-Query-Parameter. Ohne eine restriktive Referrer-Policy landen diese sensiblen Daten direkt in den Serverlogs externer Drittanbieter.

Die Referrer-Policy gehört zum Fundament jeder Security-Header-Checkliste und wirkt am stärksten im Verbund mit HSTS und einer strikten Content-Security-Policy.

Das Sicherheitsrisiko: URL-Datenabfluss in der Praxis

Ein klassisches Beispiel für ein Referrer-Datenleck:

1. Ein Nutzer fordert einen Link zur Passwort-Zurücksetzung an. Er erhält eine E-Mail mit dem Link: https://example.com/reset-password?email=kundenname@domain.ch&token=xyz123abc
2. Er ruft die Seite auf, gibt sein neues Passwort ein. Auf derselben Seite befindet sich ein Link zum Impressum des Hosters oder ein Help-Widget von Drittanbietern.
3. Klickt der Nutzer diesen externen Link an, sendet der Browser standardmässig die vollständige URL der Passwort-Seite im Referer-Header an den Hoster.
4. Der Hoster der externen Seite sieht den Token und die E-Mail-Adresse in seinen Server-Zugriffslogs. Er könnte nun das Passwort des Nutzers vor Ablauf des Tokens zurücksetzen.

---

Bewertung der Policies aus Sicherheitssicht

Webmaster müssen die Sicherheitsauswirkungen der verschiedenen Richtlinien verstehen, um die passende Schutzstufe zu wählen:

Unsichere Policies (Nicht empfohlen):

• unsafe-url: Sendet unter allen Umständen die vollständige URL (inkl. aller Parameter) – selbst beim Wechsel von sicheren HTTPS-Verbindungen auf unsicheres HTTP. Dies ist ein hohes Sicherheitsrisiko.
• no-referrer-when-downgrade: Sendet die volle URL bei HTTPS-zu-HTTPS-Verbindungen. Da heutzutage fast das gesamte Web verschlüsselt ist, schützt diese Richtlinie im Alltag kaum vor Datenlecks an Drittanbieter.

Sichere Policies (Empfohlen):

• no-referrer: Maximaler Schutz. Es werden keinerlei Referrer-Informationen übertragen.
• same-origin: Sicher für externe Links. Referrer werden nur gesendet, wenn der Nutzer auf der eigenen Domain navigiert.
• strict-origin-when-cross-origin (B2B-Standard):
  • Intern: Volle URL wird übertragen (hilfreich für interne Analysen).
  • Extern: Nur die nackte Domain (z. B. https://example.com/) wird übertragen. Parameter und Pfade werden abgeschnitten.
  • Downgrade: Wechselt der Nutzer auf HTTP, wird kein Referrer übertragen.

Alle Policies im direkten Vergleich

Die folgende Tabelle zeigt, was bei einem Klick von einer HTTPS-Seite auf ein externes Ziel jeweils übertragen wird:

Policy	Intern (gleiche Domain)	Extern (HTTPS)	Downgrade (HTTP)	Sicherheit
unsafe-url	volle URL	volle URL	volle URL	sehr schwach
no-referrer-when-downgrade	volle URL	volle URL	nichts	schwach
origin	nur Domain	nur Domain	nur Domain	mittel
strict-origin-when-cross-origin	volle URL	nur Domain	nichts	empfohlen
same-origin	volle URL	nichts	nichts	hoch
no-referrer	nichts	nichts	nichts	maximal

Die Wahl ist immer ein Kompromiss zwischen Analysebedarf und Datenschutz. Für die meisten B2B-Seiten trifft strict-origin-when-cross-origin die richtige Balance.

---

Vorher/Nachher: Ein Token-Leak schliessen

Ein Reset-Workflow leakt Tokens an ein eingebundenes Support-Widget eines Drittanbieters:

• Vorher (no-referrer-when-downgrade): Ruft der Nutzer https://app.example/reset?token=abc123 auf und löst das eingebettete Widget eine HTTPS-Anfrage an widget-provider.com aus, sendet der Browser die volle URL inklusive Token im Referer. Der Drittanbieter sieht den gültigen Reset-Token in seinen Logs.
• Nachher (strict-origin-when-cross-origin): Bei derselben externen Anfrage überträgt der Browser nur noch https://app.example/ – Pfad und Query-Parameter werden abgeschnitten. Der Token verlässt die eigene Domain nicht mehr.
• Ergebnis: Das Datenleck ist geschlossen, während interne Analysen (die die volle URL sehen dürfen) weiter funktionieren.

Die Referrer-Policy ist hier die zweite Verteidigungslinie. Die erste bleibt: keine Geheimnisse in URLs (siehe Härtungsmassnahmen unten).

---

Härtungsmassnahmen für Webentwickler

1. Keine Geheimnisse in URLs: Vermeiden Sie es grundsätzlich, sensible IDs oder Tokens in der Query-Zeile der URL zu übertragen. Nutzen Sie stattdessen POST-Payloads, Session-Cookies (mit Secure und SameSite Attributen) oder verschlüsselte Payloads.
2. Strikten Header erzwingen: Konfigurieren Sie den HTTP-Header global auf Serverebene: Referrer-Policy: strict-origin-when-cross-origin

[!TIP] Die Absicherung des Referrers schützt Ihre Benutzer vor Identitätsdiebstahl und Datenlecks. Prüfen Sie die Referrer-Sicherheit Ihrer Domain mit dem Security Header Check auf balou.tools.