Referrer-Policy: Welche URL-Informationen weitergegeben werden

Fehlender Header bedeutet nicht automatisch ein Datenleck

Der heutige Spezifikationsdefault ist strict-origin-when-cross-origin. Bei gleicher Origin kann die bereinigte vollständige URL gesendet werden; bei anderen Origins grundsätzlich nur die Origin. Beim üblichen Wechsel von öffentlichem HTTPS zu unverschlüsseltem HTTP wird kein Referrer übertragen. Browser dürfen die Informationen zusätzlich reduzieren. Chrome führte den Default ab Version 85 ein, Firefox ab 87. Alte Berichte über frühere Browserdefaults beschreiben deshalb nicht ohne Weiteres heutiges Verhalten. Referrer Policy § 3, Chrome-Umstellung, Firefox-Umstellung

Der Web Security Check bewertet den empfangenen Header der finalen Antwort und dessen bekannte Policy-Werte. Er beobachtet keine Browserrequests und erfasst damit weder spätere Meta-/Element-Policies noch JavaScript-Telemetrie. Seine Einstufung ist keine Messung aller tatsächlich übertragenen Daten.

Die acht Werte im Vergleich

Eine Origin besteht aus Schema, Host und Port. Eine andere Unterdomain oder ein anderer Port ist daher Cross-Origin, auch wenn beide Adressen zu demselben Unternehmen gehören. „URL“ in der Tabelle bedeutet die Adresse ohne Benutzerinformationen und Fragment (#…), aber grundsätzlich mit Pfad und Query. Für gewöhnliche HTTP(S)-Webadressen gilt:

Die Tabelle beschreibt die Policyregeln, keine garantierte Übertragung an jeden Empfänger. Der Entwurf entscheidet beim Sicherheitsabstieg anhand der Vertrauenswürdigkeit der URLs; lokale Loopback-Adressen sind deshalb kein allgemeiner Test für öffentliche HTTPS-zu-HTTP-Wechsel. Sehr lange Referrer können auf die Origin gekürzt werden, und Datenschutzfunktionen können weiter einschränken. Referrer Policy: Bestimmung und Bereinigung

Für eine gewöhnliche Website ist der ausdrückliche Default ein nachvollziehbarer Ausgangspunkt:

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

Wenn selbst die Herkunfts-Origin vertraulich ist oder eine sensible Seite keine Referrer weitergeben soll, kommt no-referrer infrage. Das kann Herkunftsauswertung und einzelne schlecht entworfene Integrationen verändern. Prüfen Sie diese Datenflüsse vor der Umstellung; der Referer sollte keine alleinige Zugriffskontrolle sein.

Tokens und Analytics: die verbleibenden Übertragungswege

Eine Reset-Seite mit unsafe-url kann bei einem Cross-Origin-Request auch den Query-Parameter im Referrer verraten. Dieses schematische Beispiel setzt die großzügige Policy ausdrücklich voraus:

Referrer-Policy: unsafe-url

Ausgangsseite: https://app.example.com/reset?token=SYNTHETISCH
Ressource:    https://metrics.example.net/pixel
Möglicher Referer: https://app.example.com/reset?token=SYNTHETISCH

Mit wirksamem strict-origin-when-cross-origin bleibt für diesen gewöhnlichen Cross-Origin-Fall nur https://app.example.com/. no-referrer lässt auch diese Angabe weg. Weder Policy entfernt jedoch den Parameter aus der Adresszeile, Serverprotokollen oder einem ausdrücklich damit erzeugten Link.

Ein eingebundenes Skript läuft im Kontext der Seite und kann deren Adresse unabhängig vom Referrer auslesen. Die PoPETs-Studie von Zagi, Moti und Acar (2025) untersucht diese Unterscheidung an einer eigenen Website-Stichprobe. Ihre Prozentangabe ist keine aktuelle Quote aller Websites und kein Nachweis eines Browserfehlers; für die Konfiguration entscheidend bleibt die Trennung von Header und Skriptdaten. Originalveröffentlichung

Auch Analytics ist nicht pauschal „Same-Origin“. Die GA4-Konfiguration nutzt für page_location standardmäßig document.location und für page_referrer standardmäßig document.referrer. Das sind selbst erhobene Messparameter. Eine strengere Referrer-Policy schaltet diese Messung nicht automatisch aus und verändert keine UTM-Parameter in der Zieladresse. Prüfen Sie die tatsächlich versandten Requests und die gewählten Analytics-Einstellungen. Google: GA4-Konfigurationsfelder

Header, Meta-Element und einzelne Requests

Es gibt keine allgemeine Regel „der strengste Wert gewinnt“. Der Antwortheader setzt die anfängliche Dokumentpolicy. Ein verarbeitetes Meta-Element kann sie für nachfolgende Requests ändern; Attribute und Fetch-Optionen können den einzelnen Request abweichend steuern. Ein erst spät eingefügtes Meta-Element holt bereits gesendete Requests nicht zurück. HTML: referrer-Metadaten

<meta name="referrer" content="strict-origin-when-cross-origin">
<a href="https://partner.example.net/" referrerpolicy="no-referrer">Partner</a>

fetch('/konto/status', { referrerPolicy: 'no-referrer' });

Der relative Fetch-Aufruf ist ein Modell für die eigene Anwendung, keine getestete Kontofunktion. Für einen Link kann außerdem rel="noreferrer" die Referrerübertragung unterdrücken. Eine Header-Policy ist somit keine unveränderliche Sicherheitsgrenze gegen JavaScript, das bereits in Ihrem Dokument ausgeführt wird.

Mehrere Werte im HTTP-Header sind eine Fallbackliste: Der letzte vom Browser erkannte Wert wird verwendet. Das folgende Beispiel ist syntaktisch zulässig, für aktuelle Zielbrowser aber meist nicht nötig:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

Diese Listenregel lässt sich nicht auf referrerpolicy-Attribute oder das Meta-Element übertragen. Vermeiden Sie unbeabsichtigte Doppelungen durch Anwendung und CDN. Auch Weiterleitungsantworten können die Policy des fortgesetzten Requests beeinflussen; untersuchen Sie die Kette. Externe Stylesheets können einen eigenen Referrer-/Policy-Kontext für nachgeladene Ressourcen haben. Referrer Policy: Auslieferung und Integration

Eine Änderung sicher ausrollen

1. Erfassen Sie sensible URLs, Drittressourcen, ausgehende Links und benötigte Herkunftsauswertung. Prüfen Sie zusätzlich, ob vertrauliche Daten überhaupt in die URL gehören.
2. Legen Sie den Header an der zuständigen Ausgabestelle fest und gleichen Sie Meta-Elemente, Elementattribute und Skripte ab.
3. Öffnen Sie die eigenen Testseiten in den Zielbrowsern. Betrachten Sie im Netzwerkfenster den tatsächlich gesendeten Referer, nicht nur den Antwortheader. Kontrollieren Sie Same-Origin, Cross-Origin, Weiterleitungen und besonders sensible Seiten.
4. Prüfen Sie Analytics und notwendige Partnerabläufe mit synthetischen Daten. Ein leeres document.referrer beweist nicht, dass keine anderen Informationen übertragen wurden.
5. Halten Sie die vorherige Einstellung als Rückweg bereit. Eine Rücknahme wirkt auf neu geladene Antworten; zwischengespeicherte Dokumente können weiter den alten Stand benutzen. Bereits übermittelte Daten werden dadurch nicht zurückgeholt.

Datenschutz hängt am tatsächlichen Datenfluss

URL-Informationen können vertraulich oder personenbezogen sein. Eine passende Policy kann Datenübertragungen verringern, belegt aber weder allein einen Datenschutzverstoß bei fehlendem Header noch Konformität bei vorhandenem Header. Auch Origin, Ziel-URL, Skripttelemetrie und Protokollierung gehören in die Bewertung. Weiterführend: Web-Sicherheit und Compliance.