Die HTTP-Referrer-Richtlinie verstehen: Ein Gleichgewicht zwischen Datenschutz, Sicherheit und Webfunktionalität

Haben Sie schon einmal ein Element eines Drittanbieters in Ihre Website eingebettet (z. B. eine Karte, ein Widget oder ein externes Bild) und dann festgestellt, dass es nicht funktioniert, nur eine leere Stelle anzeigt oder einen 403-Fehler („Zugriff verweigert“) zurückgibt?

Während Entwickler oft sofort nach CORS-Fehlern (Cross-Origin Resource Sharing) oder defekten Links suchen, liegt die Ursache häufig in etwas viel Einfacherem, das jedoch oft übersehen wird: der HTTP-Referrer-Richtlinie.

Im modernen Web-Ökosystem ist es ein Balanceakt, den Datenschutz der Nutzer mit nahtlosen Integrationen in Einklang zu bringen. Sind Ihre Datenschutzeinstellungen zu locker, gelangen Nutzerdaten in falsche Hände. Sind sie zu streng, blockieren externe Dienste Ihre Anfragen. In diesem Artikel gehen wir näher darauf ein, was der HTTP-Referrer-Header ist, wie die Referrer-Richtlinie diesen steuert und wie Sie ihn korrekt konfigurieren, damit Ihre Webanwendungen funktionieren, ohne die Sicherheit zu beeinträchtigen.

Was ist der HTTP "Referer" Header?

Wenn ein Nutzer auf einen Link klickt oder wenn ein Browser automatisch eine Ressource abruft (z. B. beim Laden eines Skripts, eines Bildes oder eines API-Endpunkts), sendet der Browser eine HTTP-Anfrage an den Zielserver. Früher enthielt diese Anfrage einen HTTP-Header namens „Referer“ (der in der ursprünglichen HTTP-Spezifikation fälschlicherweise mit nur einem „r“ geschrieben wurde – ein Tippfehler, der seitdem bestehen geblieben ist). Dieser Header teilt dem empfangenden Server die absolute URL der Webseite mit, von der aus die Anfrage initiiert wurde.

Wozu ist das gut?

• Analytik: Damit können Websites nachvollziehen, woher ihr Traffic stammt (beispielsweise verfolgt Google Analytics einen Besucher, der von einer Social-Media-Seite kommt).
• Zugriffskontrolle und Sicherheit: APIs und Content Delivery Networks (CDNs) nutzen diese Funktion, um zu überprüfen, ob Anfragen von autorisierten Domains stammen, und so Bandbreitendiebstahl oder Hotlinking zu verhindern.
• Protokollierung: Hilft Entwicklern dabei, Fehler aufzuspüren und den Benutzerfluss nachzuverfolgen.

Das Datenschutzproblem

Das Senden der vollständigen URL an externe Server ist zwar nützlich, birgt jedoch ein erhebliches Datenschutzrisiko. Stellen Sie sich vor, ein Nutzer befindet sich auf einer Seite zum Zurücksetzen des Passworts: example.com/reset_password?token=12345ABC. Wenn diese Seite ein externes Bild oder ein Tracking-Skript lädt, erhält der empfangende Server genau diese sensible URL (einschließlich des Zurücksetzungstokens) im Referer-Header. Um das Durchsickern sensibler Daten über Domänengrenzen hinweg zu verhindern, wurde im Rahmen der Webstandards die Referrer-Policy eingeführt.

Geben Sie die Referrer-Richtlinie ein

Die Referrer-Policy ist ein HTTP-Header (oder ein HTML-Tag <meta>), mit dem Website-Administratoren dem Browser ausdrücklich vorgeben können, wie viele Informationen im Referer-Header enthalten sein sollen, wenn der Nutzer die aktuelle Seite verlässt oder externe Ressourcen abruft.

Die gängigsten Policy Werte

Hier sind die am häufigsten verwendeten Werte und ihre Funktionen:

Wenn strenge Datenschutzvorschriften das Internet lahmlegen: Ein Beispiel aus der Praxis

Viele moderne CMS-Plattformen, Sicherheits-Plugins und Hosting-Umgebungen setzen standardmäßig zunehmend auf „Referrer-Policy: no-referrer“, um die Datenschutzbewertungen in Sicherheitstest-Tools zu maximieren. Die Verwendung des Werts „no-referrer“ macht Ihre Website jedoch für die Außenwelt im Wesentlichen anonym. Wenn Sie auf externe APIs, Zahlungsgateways oder CDNs angewiesen sind, die eine Referrer-Prüfung nutzen, um Missbrauch zu verhindern, wird Ihre Website plötzlich nicht mehr funktionieren.

Ein praktisches Beispiel: OpenStreetMap

Vor kurzem hat sich genau dieses Szenario in großem Maßstab abgespielt. Die Tile-Server von OpenStreetMap (OSM), die die von unzähligen Websites weltweit genutzten Kartengrafiken bereitstellen, haben ihre Nutzungsrichtlinien aktualisiert und verlangen nun strikt einen gültigen Referer-Header. Damit wollten sie automatisiertes Scraping und Bandbreitenmissbrauch durch anonyme Quellen unterbinden. Plötzlich stellten Website-Betreiber mit strengen Datenschutzrichtlinien fest, dass ihre interaktiven Karten durch graue Kästchen und Fehlermeldungen wie „Referer is required“ ersetzt wurden. Der Browser entfernte den Header, und OSM lehnte die anonyme Anfrage ab.

In der Phoca Maps wurde dieses Problem direkt auf Softwareebene gelöst. Da Erweiterungsentwickler weder globale Servereinstellungen noch Hosting-Einschränkungen von Drittanbietern beeinflussen können, fügt das Update explizit einen „referrerPolicy“-Parameter in die JavaScript-Initialisierung der Karte ein. Dadurch wird die globale Sperre der Website speziell für die Kartenkacheln außer Kraft gesetzt, sodass diese einwandfrei geladen werden, ohne dass die gesamte Website gezwungen ist, ihre globalen Datenschutzstandards zu senken.

So konfigurieren Sie Ihre Referrer-Richtlinie

Falls bei Ihnen externe Ressourcen blockiert werden oder Sie einfach nur die Sicherheit Ihrer Website überprüfen möchten, können Sie Ihre Richtlinien auf mehreren Ebenen festlegen.

Empfehlung: Bei den meisten modernen Websites sollten Sie darauf achten, „strict-origin-when-cross-origin“ zu verwenden.

1. Globale Webserver-Konfiguration (empfohlen)

Sie können die Richtlinie global über die Konfiguration Ihres Webservers festlegen, um sicherzustellen, dass sie für alle ausgehenden Anfragen gilt.

Apache (.htaccess):

<IfModule mod_headers.c>
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx:

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

2. CMS-Ebene (z. B. Joomla)

Moderne Content-Management-Systeme wie Joomla verfügen über eine integrierte Verwaltung von HTTP-Headern. In Joomla können Sie zu „System > Plugins > System – HTTP-Header“ navigieren, dort das Dropdown-Menü „Referrer Policy“ auswählen und den Wert auf „strict-origin-when-cross-origin“ setzen.

3. HTML-Dokumentebene

Wenn Sie keinen Zugriff auf den Server haben, können Sie die Richtlinie für eine bestimmte Seite festlegen, indem Sie einen Meta-Tag in den <head> Ihres HTML-Dokuments einfügen:

<meta name="referrer" content="strict-origin-when-cross-origin">

4. Element- und Anfrageebene (für Entwickler)

Wenn Ihre globale Website-Richtlinie streng ist (z. B. „no-referrer“), Sie aber ein bestimmtes externes Skript, Bild oder eine API-Anfrage laden müssen, können Sie die Richtlinie auf einzelne HTML-Elemente oder JavaScript-Fetch-Anfragen anwenden:

HTML-Elemente:

<img src="https://external_site.com/image.jpg" referrerpolicy="strict-origin-when-cross-origin" alt="External Image">

JavaScript Fetch API:

fetch('https://api.external_site.com/data', {
referrerPolicy: 'strict-origin-when-cross-origin'
});

Fazit

Die HTTP-Referrer-Richtlinie ist ein stiller Held der Websicherheit, der unauffällig den Informationsfluss zwischen Ihrer Website und dem Rest des Internets steuert. Auch wenn das Deaktivieren aller Referrer als ultimative Maßnahme zum Schutz der Privatsphäre erscheinen mag, ist das moderne Web ein stark vernetztes Ökosystem. Externe Anbieter benötigen grundlegende Herkunftsdaten, um sichere und stabile Dienste bereitzustellen. Durch das Verständnis und die Nutzung von Richtlinien wie „strict-origin-when-cross-origin“ können Entwickler und Website-Administratoren sensible Nutzerdaten schützen, ohne die Tools zu beeinträchtigen, die ihre Websites so erfolgreich machen.