Was ist Referrer-Policy?

Der Referrer-Policy HTTP-Header steuert, wie viel Information über die Herkunftsseite im Referer-Request-Header enthalten ist, wenn ein Nutzer von deiner Seite zu einer anderen navigiert oder wenn deine Seite Ressourcen von externen Quellen lädt. Jedes Mal, wenn jemand einen Link klickt, jedes Mal, wenn ein Bild von einem CDN geladen wird, jedes Mal, wenn ein Analyse-Skript feuert, sendet der Browser potenziell die URL der aktuellen Seite an den Zielserver. Referrer-Policy lässt dich entscheiden, wie viel von dieser URL geteilt wird.

(Eine kurze Anmerkung zur Schreibweise: Der HTTP-Header wird „Referer" mit einem „r" geschrieben, aufgrund eines Tippfehlers in der ursprünglichen HTTP-Spezifikation aus den frühen 1990ern. Der Policy-Header verwendet die korrekte Schreibweise „Referrer" mit zwei r. Beide Schreibweisen sind beabsichtigt.)

Was der Referer-Header enthält und wann er gesendet wird

Standardmäßig (ohne eine Referrer-Policy) sendet der Browser die vollständige URL der aktuellen Seite als Referer-Header mit den meisten ausgehenden Anfragen. Das umfasst:

• Navigation: Wenn ein Nutzer einen Link zu einer anderen Website klickt, erhält das Ziel die vollständige URL der Seite, von der er kam.
• Subresource-Anfragen: Wenn deine Seite Bilder, Skripte, Stylesheets oder Schriftarten von externen Domains lädt, enthält jede Anfrage den Referer-Header.
• Formular-Einreichungen: Wenn ein Formular Daten an eine externe URL sendet, wird der Referer-Header mitgesendet.
• AJAX- und Fetch-Anfragen: API-Aufrufe an externe Dienste enthalten ebenfalls standardmäßig den Referer-Header.

Angenommen, ein Besucher befindet sich auf dieser URL deiner WordPress-Seite:

https://deineseite.de/mitglieder/dashboard?session=abc123&plan=premium

Wenn diese Seite ein eingebettetes Bild eines externen Analyse-Anbieters oder Werbenetzwerks enthält, erhält der Server dieses Anbieters die vollständige URL im Referer-Header, einschließlich der Query-Parameter mit dem Session-Token und der Plan-Information. Das ist das Datenschutzproblem, das Referrer-Policy adressiert.

Alle Referrer-Policy-Werte erklärt

Der Referrer-Policy-Header unterstützt acht verschiedene Werte. Jeder definiert ein anderes Niveau der Informationsweitergabe:

• no-referrer: Niemals den Referer-Header senden. Das Ziel erhält keine Information darüber, woher die Anfrage kam. Dies ist die privateste Option, kann aber Funktionalität beschädigen, die auf Referrer-Daten angewiesen ist (manche CSRF-Schutzmechanismen zum Beispiel).
• no-referrer-when-downgrade: Die vollständige URL senden, aber den Referer bei Navigation von HTTPS zu HTTP (einem „Downgrade") entfernen. Das war jahrelang der Browser-Standard. Es schützt davor, URLs beim Verlassen eines sicheren Kontexts preiszugeben, teilt aber alles bei HTTPS-zu-HTTPS-Navigation.
• origin: Nur den Ursprung (Schema, Host und Port) senden, nicht den Pfad oder die Query-Parameter. So wird aus https://deineseite.de/mitglieder/dashboard?session=abc123 nur https://deineseite.de/. Das Ziel weiß, von welcher Seite der Besucher kam, aber nicht von welcher spezifischen Unterseite.
• origin-when-cross-origin: Die vollständige URL für Same-Origin-Anfragen senden (Links innerhalb deiner eigenen Seite), aber nur den Ursprung für Cross-Origin-Anfragen. Das gibt deinen eigenen Analyse-Tools und internen Werkzeugen vollständige Referrer-Daten, während eingeschränkt wird, was externe Seiten sehen.
• same-origin: Die vollständige URL nur für Same-Origin-Anfragen senden. Für Cross-Origin-Anfragen keinen Referer senden. Das ist sehr privat für externe Navigation, bedeutet aber, dass externe Dienste keinerlei Referrer-Daten erhalten.
• strict-origin: Nur den Ursprung senden (wie der origin-Wert), aber den Referer bei HTTPS-zu-HTTP-Downgrades komplett entfernen. Kombiniert die Privatheit von origin mit dem Downgrade-Schutz von no-referrer-when-downgrade.
• strict-origin-when-cross-origin: Der am häufigsten empfohlene Wert. Er sendet die vollständige URL für Same-Origin-Anfragen, nur den Ursprung für Cross-Origin HTTPS-zu-HTTPS-Anfragen und nichts für HTTPS-zu-HTTP-Downgrades. Das ist die beste Balance zwischen Privatheit, Sicherheit und Funktionalität. Moderne Browser (Chrome 85+, Firefox 87+) haben diesen Wert als Standard übernommen, selbst wenn kein Referrer-Policy-Header vorhanden ist.
• unsafe-url: Immer die vollständige URL senden, unabhängig vom Ziel oder Sicherheitskontext. Dieser Wert heißt nicht ohne Grund „unsafe". Er sendet Query-Parameter, Pfade und alles andere sogar an HTTP-Ziele. Verwende dies nie, es sei denn, du hast einen sehr spezifischen Bedarf und verstehst die Risiken.

Datenschutz-Implikationen des Referer-Headers

Der Referer-Header ist ein bedeutendes Datenschutzproblem, das viele Seitenbetreiber übersehen. Bedenke, welche Informationen deine URLs enthalten könnten:

• Suchanfragen: Wenn deine Seite eine Suchfunktion hat, könnte die URL /suche?q=sensibles+gesundheitsthema lauten. Jede externe Ressource, die auf der Suchergebnisseite geladen wird, erhält diese Anfrage.
• Nutzer-Identifikatoren: URLs wie /user/max-mustermann/profil oder /bestellung/12345 geben Nutzer- und Bestellinformationen an externe Parteien weiter.
• Tokens und Sitzungsdaten: Manche Anwendungen setzen Tokens in URLs für Passwortzurücksetzungen, E-Mail-Bestätigungen oder Teilen-Links. Diese könnten über den Referer-Header preisgegeben werden.
• Interne URL-Struktur: Selbst nur die Pfadstruktur (/wp-admin/, /nur-fuer-mitglieder/, /internes-dashboard/) verrät Informationen über die Architektur deiner Seite.

Jede Drittanbieter-Ressource auf deiner Seite ist ein potenzieller Empfänger dieser Informationen: Google Fonts, Analyse-Skripte, Social-Media-Buttons, eingebettete Videos, Werbenetzwerke, CDN-gehostete Bibliotheken und externe Bilder. Jede einzelne erhält den Referer-Header mit ihren Anfragen.

DSGVO und Datenschutz-Relevanz

Unter der DSGVO und ähnlichen Datenschutzgesetzen können URLs, die persönliche Identifikatoren oder sensible Informationen enthalten, personenbezogene Daten darstellen. Wenn deine URLs Nutzernamen, E-Mail-Adressen oder andere identifizierende Informationen enthalten, könnte die Weitergabe dieser URLs über den Referer-Header an Dritte ein Datenschutzproblem sein.

Das Setzen einer Referrer-Policy ist eine unkomplizierte technische Maßnahme, die unnötige Datenweitergabe an Dritte reduziert. Obwohl sie nicht explizit von der DSGVO verlangt wird, steht sie im Einklang mit den Prinzipien der Datenminimierung (Artikel 5(1)(c)) und des Datenschutzes durch Technikgestaltung (Artikel 25). Wenn dein Datenschutzbeauftragter oder ein Datenschutz-Audit fragt, welche technischen Maßnahmen du zur Begrenzung von Datenlecks implementiert hast, ist eine korrekte Referrer-Policy ein konkreter Punkt, auf den du verweisen kannst.

WordPress-Standardverhalten und gängige Plugins

WordPress-Core setzt standardmäßig keinen Referrer-Policy-Header. Das bedeutet, deine Seite verlässt sich auf den eingebauten Standard des jeweiligen Browsers. Für moderne Browser ist dieser Standard strict-origin-when-cross-origin, was tatsächlich eine vernünftige Richtlinie ist. Allerdings gibt es einige Punkte zu beachten:

• Ältere Browser verwenden möglicherweise noch no-referrer-when-downgrade als Standard, was die vollständige URL bei allen HTTPS-zu-HTTPS-Anfragen sendet.
• Den Header explizit zu setzen, ist besser, als sich auf Browser-Standards zu verlassen, weil es deine Absicht klar kommuniziert und alle Browser-Versionen abdeckt.
• Einige WordPress-Sicherheitsplugins (wie Sucuri oder iThemes Security) bieten eine Referrer-Policy-Option in ihren Härtungseinstellungen.
• WordPress 4.7.4 führte Verbesserungen der wp_get_referer()-Funktion ein, aber das ist eine serverseitige Funktion, die den Referer-Header für CSRF-Schutz liest. Sie steht nicht in Zusammenhang mit dem Referrer-Policy-Response-Header.

Auswirkungen auf Website-Analytics

Deine Referrer-Policy-Wahl beeinflusst direkt, welche Referrer-Daten deine Analyse-Tools erhalten und welche Daten andere Seiten über Traffic von deiner Seite erhalten:

• Eigene Analytics: Wenn du Google Analytics, Matomo oder ein ähnliches Tool mit einem Tracking-Skript auf deiner Seite verwendest, enthalten Same-Origin-Anfragen immer den vollständigen Referrer, unabhängig von der Richtlinie (die meisten Richtlinien beschränken nur Cross-Origin-Referrer). Deine On-Site-Analysedaten werden durch die meisten Richtlinien-Werte nicht beeinträchtigt.
• Eingehende Traffic-Verfolgung: Die Referrer-Policy, die du setzt, beeinflusst, was andere Seiten sehen, wenn deine Besucher von deiner Seite kommen. Sie beeinflusst nicht, was du über Traffic siehst, der zu deiner Seite kommt (das hängt von der Richtlinie der verweisenden Seite ab).
• Affiliate- und Partner-Tracking: Wenn du ein Affiliate-Programm betreibst oder ausgehende Klicks verfolgen musst, wird eine sehr restriktive Richtlinie wie no-referrer das referrer-basierte Tracking beschädigen. Das empfohlene strict-origin-when-cross-origin sendet den Ursprung (Domain) an Partner, was für die Zuordnung normalerweise ausreicht.

Referrer-Policy für WordPress einrichten

Der empfohlene Wert für die meisten WordPress-Seiten ist strict-origin-when-cross-origin:

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

Um ihn in Apache zu setzen:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

In Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Per PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Wenn deine Seite besonders sensible Daten verarbeitet (medizinische Informationen, Finanzdaten, juristische Dokumente), könntest du eine striktere Richtlinie wie same-origin oder no-referrer in Betracht ziehen. Beachte aber, dass dadurch die Referrer-Information für alle Cross-Origin-Anfragen entfernt wird, was externe Dienste beeinträchtigen kann, die darauf angewiesen sind.

Was InspectWP prüft

InspectWP prüft, ob deine WordPress-Seite einen Referrer-Policy-Header sendet, und meldet den konfigurierten Wert. Wenn der Header fehlt, hängt deine Seite vom Standard des jeweiligen Browsers jedes Besuchers ab, der je nach Browser-Version variiert. Das explizite Setzen einer Referrer-Policy stellt konsistentes Verhalten sicher und zeigt, dass du eine bewusste Entscheidung darüber getroffen hast, wie viel URL-Information deine Seite mit Dritten teilt. Für die große Mehrheit der WordPress-Seiten ist strict-origin-when-cross-origin der empfohlene Wert.