Referrer-Policy im HTTP verständlich erklärt: Browser-Verhalten

Der HTTP-Response-Header Referrer-Policy steuert das Verhalten des Webbrowsers beim Navigieren über Links oder beim Laden externer Ressourcen (Bilder, Skripte). Er legt fest, wie viel Adressinformationen der Browser im Referer-Anfrage-Header an die Zielwebsite mitsendet. Dies schützt die Privatsphäre der Nutzer und verhindert, dass sensible interne URLs (die z. B. Token oder IDs enthalten) an Drittanbieter abfliessen.

[!NOTE] Diese Seite betrachtet die Referrer-Policy aus der HTTP-Header-Perspektive: Syntax, Werte und das konkrete Browser-Verhalten beim Setzen des Referer-Headers. Die Einordnung als Sicherheits- und Datenschutzmassnahme im Verbund mit anderen Schutz-Headern finden Sie auf der Seite Referrer-Policy als Security-Header.

Der Referrer-Mechanismus im Web

Klickt ein Benutzer auf einer Website A (z. B. https://allerate.com/produkte/) einen Link zu Website B (z. B. https://externe-seite.de), sendet der Browser bei der Anfrage an B den Header Referer mit:

GET / HTTP/1.1
Host: externe-seite.de
Referer: https://allerate.com/produkte/

Website B kann dadurch auswerten, von welcher exakten Unterseite der Besucher gekommen ist. Das kann für Webanalysen nützlich sein, birgt jedoch erhebliche Datenschutzrisiken:

• Enthält eine interne URL sensible Daten (z. B. https://allerate.com/internal/reset-password?token=abc123xyz), liest die externe Seite diesen Token über den Referrer aus und kann die Sitzung kapern.

---

Die verschiedenen Referrer-Policy-Werte

Über den Server-Antwort-Header Referrer-Policy können Webmaster das Verhalten des Browsers präzise regulieren:

• no-referrer: Der Browser sendet unter keinen Umständen Referrer-Informationen mit. Der Referer-Header in der Anfrage bleibt komplett leer.
• no-referrer-when-downgrade: Sendet die volle URL bei Verbindungen mit gleicher Sicherheitsstufe (HTTPS → HTTPS). Wechselt der Nutzer von HTTPS auf unverschlüsseltes HTTP, wird kein Referrer gesendet.
• same-origin: Sendet die volle URL nur bei internen Links auf der eigenen Domain. Bei Klicks auf externe Domains wird kein Referrer gesendet.
• origin: Sendet ausschliesslich die Domain (Origin, z. B. https://allerate.com/) anstelle des vollständigen Pfades – sowohl intern als auch extern.
• strict-origin-when-cross-origin (Moderner Standard):
  • Bei internen Aufrufen (Same-Origin) wird die vollständige URL gesendet.
  • Bei externen Aufrufen (Cross-Origin) von HTTPS zu HTTPS wird nur die nackte Domain gesendet.
  • Bei einem Wechsel von HTTPS zu unverschlüsseltem HTTP wird kein Referrer gesendet.

---

Die Werte im direkten Vergleich

Die folgende Tabelle zeigt, welche Referrer-Informationen die einzelnen Richtlinien bei internen (Same-Origin) und externen (Cross-Origin) Aufrufen übertragen:

Policy-Wert	Same-Origin	Cross-Origin (HTTPS→HTTPS)	HTTPS→HTTP
no-referrer	nichts	nichts	nichts
same-origin	volle URL	nichts	nichts
origin	nur Domain	nur Domain	nur Domain
strict-origin	nur Domain	nur Domain	nichts
no-referrer-when-downgrade	volle URL	volle URL	nichts
strict-origin-when-cross-origin	volle URL	nur Domain	nichts
unsafe-url	volle URL	volle URL	volle URL

Die Werte sind nach steigender Datenfreigabe sortiert: no-referrer ist am restriktivsten, unsafe-url gibt selbst bei einem Downgrade auf unverschlüsseltes HTTP die vollständige URL preis – und sollte deshalb praktisch nie verwendet werden.

---

Vorher/Nachher: Ein Token-Leak schliessen

Ein häufiges Datenschutzproblem entsteht, wenn interne URLs sensible Parameter enthalten und Nutzende von dort auf eine externe Seite klicken:

• Vorher (unsafe-url oder keine Policy): Ein Nutzer öffnet https://app.example.com/reset?token=abc123 und klickt im Footer auf einen externen Partnerlink. Der Browser sendet die vollständige URL inklusive Token im Referer-Header an die Drittseite. Deren Server-Logs enthalten nun einen gültigen Passwort-Reset-Token.
• Nachher (strict-origin-when-cross-origin): Bei externen Klicks sendet der Browser nur noch die nackte Domain https://app.example.com/. Der Token bleibt vertraulich, während interne Navigation und die eigene Webanalyse weiterhin die volle URL erhalten.

Die Lehre: Die Referrer-Policy ist eine wirksame, mit einer einzigen Header-Zeile umsetzbare Massnahme gegen unbeabsichtigte Datenabflüsse – und ergänzt strengere Schutzmechanismen wie die Content-Security-Policy.

---

Best Practice Empfehlung

Für die meisten B2B-Websites ist strict-origin-when-cross-origin die beste Balance zwischen Datenschutz und Marketing-Anforderungen:

Referrer-Policy: strict-origin-when-cross-origin

Sie schützt vor Datenabflüssen bei externen Links, erlaubt es Webmastern der eigenen Properties aber weiterhin zu sehen, von welcher Domain ihre Besucher stammen. Wer einzelne Links feiner steuern möchte, kombiniert die globale Policy mit dem referrerpolicy-Attribut oder – etwa bei Weiterleitungen auf externe Ziele – mit rel="noreferrer".

[!TIP] Um den Referrer-Schutz noch feiner abzustimmen, können Sie auch das HTML-Attribut rel="noreferrer" direkt auf einzelnen <a>-Link-Tags platzieren. Prüfen Sie die Referrer-Auslieferung Ihrer Website mit dem HTTP Header Check auf balou.tools.