Was ist Referrer-Policy?

Der Referrer-Policy HTTP-Header steuert, wie viel Information ueber 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 laedt. 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 laesst 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 urspruenglichen HTTP-Spezifikation aus den fruehen 1990ern. Der Policy-Header verwendet die korrekte Schreibweise "Referrer" mit zwei r. Beide Schreibweisen sind beabsichtigt.)

Was der Referer-Header enthaelt und wann er gesendet wird

Standardmaessig (ohne eine Referrer-Policy) sendet der Browser die vollstaendige 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, erhaelt das Ziel die vollstaendige URL der Seite, von der er kam.
• Subresource-Anfragen: Wenn deine Seite Bilder, Skripte, Stylesheets oder Schriftarten von externen Domains laedt, enthaelt 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 standardmaessig 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 enthaelt, erhaelt der Server dieses Anbieters die vollstaendige URL im Referer-Header, einschliesslich der Query-Parameter mit dem Session-Token und der Plan-Information. Das ist das Datenschutzproblem, das Referrer-Policy adressiert.

Alle Referrer-Policy-Werte erklaert

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

• no-referrer: Niemals den Referer-Header senden. Das Ziel erhaelt keine Information darueber, woher die Anfrage kam. Dies ist die privateste Option, kann aber Funktionalitaet beschaedigen, die auf Referrer-Daten angewiesen ist (manche CSRF-Schutzmechanismen zum Beispiel).
• no-referrer-when-downgrade: Die vollstaendige URL senden, aber den Referer bei Navigation von HTTPS zu HTTP (einem "Downgrade") entfernen. Das war jahrelang der Browser-Standard. Es schuetzt 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 weiss, von welcher Seite der Besucher kam, aber nicht von welcher spezifischen Unterseite.
• origin-when-cross-origin: Die vollstaendige URL fuer Same-Origin-Anfragen senden (Links innerhalb deiner eigenen Seite), aber nur den Ursprung fuer Cross-Origin-Anfragen. Das gibt deinen eigenen Analyse-Tools und internen Werkzeugen vollstaendige Referrer-Daten, waehrend eingeschraenkt wird, was externe Seiten sehen.
• same-origin: Die vollstaendige URL nur fuer Same-Origin-Anfragen senden. Fuer Cross-Origin-Anfragen keinen Referer senden. Das ist sehr privat fuer 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 haeufigsten empfohlene Wert. Er sendet die vollstaendige URL fuer Same-Origin-Anfragen, nur den Ursprung fuer Cross-Origin HTTPS-zu-HTTPS-Anfragen und nichts fuer HTTPS-zu-HTTP-Downgrades. Das ist die beste Balance zwischen Privatheit, Sicherheit und Funktionalitaet. Moderne Browser (Chrome 85+, Firefox 87+) haben diesen Wert als Standard uebernommen, selbst wenn kein Referrer-Policy-Header vorhanden ist.
• unsafe-url: Immer die vollstaendige URL senden, unabhaengig vom Ziel oder Sicherheitskontext. Dieser Wert heisst 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 uebersehen. Bedenke, welche Informationen deine URLs enthalten koennten:

• Suchanfragen: Wenn deine Seite eine Suchfunktion hat, koennte die URL /suche?q=sensibles+gesundheitsthema lauten. Jede externe Ressource, die auf der Suchergebnisseite geladen wird, erhaelt 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 fuer Passwortzuruecksetzungen, E-Mail-Bestaetigungen oder Teilen-Links. Diese koennten ueber den Referer-Header preisgegeben werden.
• Interne URL-Struktur: Selbst nur die Pfadstruktur (/wp-admin/, /nur-fuer-mitglieder/, /internes-dashboard/) verraet Informationen ueber die Architektur deiner Seite.

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

DSGVO und Datenschutz-Relevanz

Unter der DSGVO und aehnlichen Datenschutzgesetzen koennen URLs, die persoenliche Identifikatoren oder sensible Informationen enthalten, personenbezogene Daten darstellen. Wenn deine URLs Nutzernamen, E-Mail-Adressen oder andere identifizierende Informationen enthalten, koennte die Weitergabe dieser URLs ueber den Referer-Header an Dritte ein Datenschutzproblem sein.

Das Setzen einer Referrer-Policy ist eine unkomplizierte technische Massnahme, die unnoetige 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 Massnahmen du zur Begrenzung von Datenlecks implementiert hast, ist eine korrekte Referrer-Policy ein konkreter Punkt, auf den du verweisen kannst.

WordPress-Standardverhalten und gaengige Plugins

WordPress-Core setzt standardmaessig keinen Referrer-Policy-Header. Das bedeutet, deine Seite verlaesst sich auf den eingebauten Standard des jeweiligen Browsers. Fuer moderne Browser ist dieser Standard strict-origin-when-cross-origin, was tatsaechlich eine vernuenftige Richtlinie ist. Allerdings gibt es einige Punkte zu beachten:

• Aeltere Browser verwenden moeglicherweise noch no-referrer-when-downgrade als Standard, was die vollstaendige 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 Haertungseinstellungen.
• WordPress 4.7.4 fuehrte Verbesserungen der wp_get_referer()-Funktion ein, aber das ist eine serverseitige Funktion, die den Referer-Header fuer 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 ueber Traffic von deiner Seite erhalten:

• Eigene Analytics: Wenn du Google Analytics, Matomo oder ein aehnliches Tool mit einem Tracking-Skript auf deiner Seite verwendest, enthalten Same-Origin-Anfragen immer den vollstaendigen Referrer, unabhaengig von der Richtlinie (die meisten Richtlinien beschraenken nur Cross-Origin-Referrer). Deine On-Site-Analysedaten werden durch die meisten Richtlinien-Werte nicht beeintraechtigt.
• 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 ueber Traffic siehst, der zu deiner Seite kommt (das haengt 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 beschaedigen. Das empfohlene strict-origin-when-cross-origin sendet den Ursprung (Domain) an Partner, was fuer die Zuordnung normalerweise ausreicht.

Referrer-Policy fuer WordPress einrichten

Der empfohlene Wert fuer 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), koenntest du eine striktere Richtlinie wie same-origin oder no-referrer in Betracht ziehen. Beachte aber, dass dadurch die Referrer-Information fuer alle Cross-Origin-Anfragen entfernt wird, was externe Dienste beeintraechtigen kann, die darauf angewiesen sind.

Was InspectWP prueft

InspectWP prueft, ob deine WordPress-Seite einen Referrer-Policy-Header sendet, und meldet den konfigurierten Wert. Wenn der Header fehlt, haengt 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 darueber getroffen hast, wie viel URL-Information deine Seite mit Dritten teilt. Fuer die grosse Mehrheit der WordPress-Seiten ist strict-origin-when-cross-origin der empfohlene Wert.