Referrer und Best Practices für Referrer-Richtlinien
Best Practices für das Festlegen Ihrer Referrer-Richtlinie (Referrer-Policy) und für die Nutzung von Referrern in eingehenden Anfragen.
Zusammenfassung #
- Unerwartete Cross-Origin-Informationslecks beeinträchtigen die Privatsphäre der Webbenutzer. Eine schützende Referrer-Richtlinie kann dagegen helfen.
- Ziehen Sie in Erwägung, eine Referrer-Richtlinie von
strict-origin-when-cross-origin
festzulegen. Diese bewahrt einen großen Teil der Nützlichkeit des Referrers und verringert gleichzeitig das Risiko von Datenlecks zwischen verschiedenen Origins (cross-origin). - Verwenden Sie zum Schutz vor Cross-Site Request Forgery (CSRF) keine Referrer. Nutzen Sie stattdessen für eine zusätzliche Sicherheitsebene CSRF-Token und andere Header.
Referer und Referrer-Richtlinie 101 #
HTTP requests may include the optional Referer
header, which indicates the origin or web page URL the request was made from. The Referrer-Policy
header defines what data is made available in the Referer
header.
Im folgenden Beispiel enthält der Referer
-Header die vollständige URL der Seite unter site-one
, von der aus die Anfrage gestellt wurde.
Der Referer
-Header kann in verschiedenen Arten von Anfragen vorhanden sein:
- Navigationsanfragen, wenn ein Benutzer auf einen Link klickt
- Anfragen zu Unterressourcen, wenn ein Browser Bilder, iframes, Skripte und andere Ressourcen anfordert, die von einer Seite benötigt werden.
Zur Navigation und für iframes können diese Daten auch per JavaScript mit document.referrer
abgerufen werden.
Der Referer
-Wert kann aufschlussreich sein. Beispielsweise könnte ein Analysedienst den Wert verwenden, um zu bestimmen, dass 50 % der Besucher auf site-two.example
von social-network.example
kamen.
Wenn jedoch die vollständige URL einschließlich des Pfads perReferer
zwischen verschiedenen Origins geteilt wird, kann dies nicht nur die Privatsphäre beeinträchtigen sondern ebenfalls Sicherheitsrisiken bergen. Sehen Sie sich beispielsweise diese URLs an:
Die URLs #1 bis #5 enthalten private Informationen – manche sogar identifizierende oder vertrauliche. Wenn diese stillschweigend zu anderen Origins durchsickern, kann dies die Privatsphäre der Webbenutzer gefährden.
URL #6 ist eine Funktions-URL. Man möchte nicht, dass sie in die Hände von jemand anderem als dem gewünschten Benutzer fällt. In diesem Fall könnte ein böswilliger Akteur das Konto dieses Benutzers kapern.
Um einzuschränken, welche Referrer-Daten für Anfragen von Ihrer Website zur Verfügung gestellt werden, können Sie eine Referrer-Richtlinie festlegen.
Welche Richtlinien gibt es und wie unterscheiden sie sich? #
Sie können eine von acht Richtlinien auswählen. Abhängig von der Richtlinie können die im Referer
-Header (und über document.referrer
) verfügbaren Daten:
- Nicht vorhanden sein (kein
Referer
-Header vorhanden) - Nur die Origins betreffen
- Die vollständige URL enthalten: Origin, Pfad und Query-String

Einige Richtlinien wurden so gestaltet, dass Sie je nach Kontext unterschiedliches Verhalten hervorrufen, beispielsweise im Kontext einer Cross-Origin- bzw. Same-Origin-Anfrage, wenn erhöht Wert auf die Sicherheit (das Ziel der Anfrage sollte genauso sicher sein wie die Origin) gelegt wird oder wenn beides der Fall ist. Dies ist nützlich, um die Menge an Informationen zu begrenzen, die über Origins hinweg (cross-origin) oder mit weniger sicheren Origins geteilt werden – während gleichzeitig die Vielfalt des Referrers auf Ihrer eigenen Site erhalten bleibt.
Hier ist eine Übersicht, die zeigt, wie Referrer-Richtlinien die im Referer-Header und über document.referrer
verfügbaren URL-Daten einschränken:
MDN bietet eine vollständige Liste mit Richtlinien und Verhaltensbeispielen an.
Dinge zu beachten:
- Alle Richtlinien, die das Schema (HTTPS vs. HTTP) berücksichtigen (
strict-origin
,no-referrer-when-downgrade
undstrict-origin-when-cross-origin
) behandeln Anfragen von einer HTTP-Origin zu einer anderen HTTP-Origin genauso wie Anfragen von einer HTTPS-Origin zu einer anderen HTTPS-Oigin – auch wenn HTTP unsicherer ist. Der Grund dafür ist, dass es im Rahmen der Richtlinien entscheidend ist, ob ein Sicherheits-Downgrade stattfindet, also ob die Anfrage Daten einer verschlüsselten Origin einer unverschlüsselten Origin preisgeben kann. Eine HTTP → HTTP-Anfrage bleibt die ganze Zeit über unverschlüsselt, ein Downgrade findet nicht statt. Bei HTTPS → HTTP-Anfragen wird hingegen ein Downgrade durchgeführt. - Wenn eine Anfrage eine Same-Origin-Anfrage ist, stimmt das Schema (HTTPS oder HTTP) überein, was bedeutet, dass kein Sicherheits-Downgrade vollzogen wird.
Standardmäßige Referrer-Richtlinien in Browsern #
Stand Oktober 2021
Wenn keine Referrer-Richtlinie (Refferer-Policy) festgelegt wurde, wird die Standardrichtlinie des Browsers verwendet.
Festlegen Ihrer Referrer-Richtlinie: Best Practices #
Es gibt verschiedene Möglichkeiten, die Referrer-Richtlinien Ihrer Website festzulegen:
- Per HTTP-Header
- In Ihrem HTML-Code
- Auf Anfragebasis per JavaScript
Sie können unterschiedliche Richtlinien für verschiedene Seiten, Anfragen oder Elemente festlegen.
Der HTTP-Header und das Meta-Element befinden sich beide auf Seitenebene. Die bei der Bestimmung der für ein Element geltenden Richtlinie geltende Reihenfolge lautet:
- Richtlinie für die Elementebene
- Richtlinie für die Seitenebene
- Standardeinstellung des Browsers
Beispiel:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
Das Bild wird mit einer geltenden Richtlinie von no-referrer-when-downgrade
angefordert, während alle anderen Unterressourcenanfragen dieser Seite der Richtlinie strict-origin-when-cross-origin
folgen.
Wie kann ich die Referrer-Richtlinie einsehen? #
Die Website securityheaders.com kann dabei helfen, die von einer bestimmten Website oder Seite angewendete Richtlinie zu bestimmen.
Sie können ebenfalls die Entwicklertools von Chrome, Edge oder Firefox nutzen, um die von einer bestimmten Anfrage genutzte Referrer-Richtlinie anzuzeigen. Zum Zeitpunkt der Erstellung dieses Artikels kann Safari den Referrer-Policy
-Header nicht anzeigen, zeigt allerdings den gesendeten Referer
an.
Welche Richtlinie sollten Sie für Ihre Website festlegen? #
Zusammenfassung: Legen Sie explizit eine den Datenschutz verbessernde Richtlinie wie strict-origin-when-cross-origin
(oder eine strengere) fest.
Warum „explizit“? #
Wenn keine Referrer-Richtlinie festgelegt wurde, wird die Standardrichtlinie des Browsers verwendet – tatsächlich greifen Websites oft auf diese Standardrichtlinie des Browsers zurück. Dies ist jedoch nicht ideal, denn:
- Die Standardrichtlinien von Browsern sind entweder
no-referrer-when-downgrade
,strict-origin-when-cross-origin
oder strengere – je nach Browser und Modus (privat/inkognito). Das Verhalten Ihrer Website in verschiedenen Browsern ist also nicht vorhersehbar. - Browser verwenden strengere Standardeinstellungen wie
strict-origin-when-cross-origin
und Mechanismen wie Referrer-Trimming für Cross-Origin-Anfragen. Wenn Sie sich explizit für eine Datenschutzrichtlinie entscheiden, bevor sich die Browser-Standardeinstellungen ändern, haben Sie die Kontrolle und können nach Belieben Tests durchführen.
Weshalb strict-origin-when-cross-origin
(oder strenger)? #
Sie benötigen eine sichere, datenschutzfreundliche und nützliche Richtlinie – was „nützlich“ dabei genau bedeutet, hängt davon ab, was Sie vom Referrer erwarten:
- Sicherheit: Wenn Ihre Website HTTPS verwendet (wenn nicht, machen Sie dies zu einer Priorität), möchten Sie nicht, dass die URLs Ihrer Website an Nicht-HTTPS-Anfragen durchsickern. Da jeder im Netzwerk diese sehen kann, würde dies Ihre Benutzer Person-in-the-Middle-Angriffen aussetzen. Die Richtlinien
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
undstrict-origin
lösen dieses Problem. - Verbesserung der Privatsphäre: Bei einer Cross-Origin-Anfrage wird im Rahmen der Richtlinie
no-referrer-when-downgrade
die vollständige URL geteilt – dies schützt nicht die Privatsphäre.strict-origin-when-cross-origin
undstrict-origin
teilen nur die Origin mit, undno-referrer
gibt gar nichts preis. Damit bleiben Ihnen zum Schutz der Privatsphäre nur noch die Optionenstrict-origin-when-cross-origin
,strict-origin
undno-referrer
übrig. - Nützlich:
no-referrer
undstrict-origin
teilen nie die vollständige URL, selbst bei Anfragen mit gleichem Ursprungspunkt. Wenn Sie dies benötigen, iststrict-origin-when-cross-origin
bessere Option.
Daraus lässt sich schließen, dass strict-origin-when-cross-origin
im Allgemeinen eine sinnvolle Wahl ist.
Beispiel: Festlegen einer Richtlinie von strict-origin-when-cross-origin
:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
Oder serverseitig, zum Beispiel per Express-Framework:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
Was ist, wenn strict-origin-when-cross-origin
(oder strenger) nicht für alle Ihre Anwendungsfälle geeignet ist? #
Gehen Sie in diesem Fall progressiv vor: Legen Sie für Ihre Website eine schützende Richtlinie wie strict-origin-when-cross-origin
und bei Bedarf eine eher tolerantere Richtlinie für spezifische Anfragen oder HTML-Elemente fest.
Beispiel: Richtlinie für die Elementebene #
index.html
:
<head>
<!-- document-level policy: strict-origin-when-cross-origin -->
<meta name="referrer" content="strict-origin-when-cross-origin" />
<head>
<body>
<!-- policy on this <a> element: no-referrer-when-downgrade -->
<a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
<body></body>
</body>
</head>
</head>
Beachten Sie, dass Safari/WebKit document.referrer
oder den Referer
-Header für Cross-Site-Anfragen blockieren könnte. Siehe weitere Details.
Beispiel: Richtlinie für die Anfrageebene #
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
Was sollten Sie weiteres beachten? #
Ihre Richtlinie sollten Sie entsprechend Ihrer Website und den spezifischen Anwendungsfällen wählen – diese Entscheidung liegt bei Ihnen, Ihrem Team und Ihrem Unternehmen. Wenn einige der URLs identifizierende oder sensible Daten enthalten, stellen Sie eine Richtlinie ein, bei der der Fokus auf dem Datenschutz liegt.
Verwendung des Referrers aus eingehenden Anfragen: Best Practices #
Was ist zu tun, wenn die Funktionalität Ihrer Website die Referrer-URL eingehender Anfragen verwendet? #
Schützen Sie die Benutzerdaten #
Der Referer
kann private, personenbezogene oder identifizierende Daten enthalten – stellen Sie also sicher, dass Sie diese auch als solche behandeln.
Denken Sie daran, dass sich von ihnen erhaltene Referer
ändern können #
Die Verwendung des Referrers aus eingehenden Cross-Origin-Anfragen bringt einige Einschränkungen mit sich:
- Wenn Sie keine Kontrolle über die Implementierung der für das Senden der Anfragen genutzten Software haben, können Sie auch keine Annahmen über den erhaltenen
Referer
-Header (sowie überdocument.referrer
) anstellen. Der Emittent der Anfrage kann sich jederzeit entscheiden, zu einerno-referrer
-Richtlinie oder einer insgesamt strengeren Richtlinie im Vergleich zu vorher zu wechseln. Damit würden Sie weniger Daten über denReferer
erhalten als früher. - Immer mehr Browser verwenden standardmäßig die Referrer-Richtlinie
strict-origin-when-cross-origin
. Dies bedeutet, dass Sie die Origin (anstelle der vollständigen Referrer-URL) mit eingehenden Cross-Origin-Anfragen jetzt möglicherweise nur noch mitgeteilt bekommen, wenn die Site, die diese sendet, keine Richtlinien festgelegt hat. - Browser könnten in Zukunft die Art und Weise ändern, auf die sie mit dem
Referer
umgehen. Beispielsweise könnten sie in Zukunft beschließen, Referrerinhalte in Cross-Origin-Anfragen für Unterressourcen immer auf die Origins zu beschränken, um die Privatsphäre der Benutzer zu schützen. - Der
Referer
-Header (sowiedocument.referrer
) kann mehr Daten enthalten, als Sie benötigen, beispielsweise eine vollständige URL, wenn Sie lediglich wissen möchten, ob es sich um eine Cross-Origin-Anfrage handelt.
Alternativen zu Referer
#
Möglicherweise müssen Sie Alternativen in Betracht ziehen, wenn:
- Eine wesentliche Funktion Ihrer Website die Referrer-URL eingehender Cross-Origin-Anfragen nutzt;
- Und/oder wenn Ihre Website den benötigten Teil der Referrer-URL aus einer Cross-Origin-Anfrage nicht mehr erhält. Dies geschieht, wenn der Sender der Anfrage seine Richtlinie geändert hat oder wenn keine Richtlinie festgelegt wurde und die Richtlinie des Browsers geändert wurde (wie in Chrome 85).
Um Alternativen zu definieren, analysieren Sie zuerst, welchen Teil des Referrers Sie verwenden.
Wenn Sie lediglich die Origin benötigen (https://site-one.example
):
- Wenn Sie den Referrer in einem Skript verwenden, das Zugriff auf die oberste Ebene der Seite hat, ist
window.location.origin
eine Alternative. - Wenn verfügbar, geben Header wie
Origin
undSec-Fetch-Site
dieOrigin
an oder beschreiben, ob es sich um eine Cross-Origin-Anfrage handelt, was möglicherweise genau das ist, was Sie brauchen.
Wenn Sie andere Elemente der URL benötigen (Pfad, Query-Parameter usw.):
- Gibt es eventuell Anfrageparameter die auf Ihren Anwendungsfall zugeschnitten sind, was Ihnen das Parsen des Referrers erspart.
- Dann kann, wenn Sie den Referrer in einem Skript verwenden, das Zugriff auf die oberste Ebene einer Seite hat,
window.location.pathname
eine Alternative sein. Extrahieren Sie nur den Pfadabschnitt der URL und übergeben Sie ihn als Argument, damit keine potenziell sensiblen Informationen über die URL-Parameter weitergegeben werden.
Wenn Sie diese Alternativen nicht verwenden können:
- Prüfen Sie, ob Ihre Systeme so angepasst werden können, dass vom Sender der Anfrage (
site-one.example
) erwartet wird, dass die von Ihnen benötigten Informationen von ihm explizit in einer Art Konfiguration festlegt werden. Vorteile: expliziter, datenschutzfreundlicher für Benutzer vonsite-one.example
und zukunftssicherer. Nachteile: möglicherweise mehr Arbeit von Ihrer Seite oder für die Benutzer Ihres Systems. - Prüfen Sie, ob die Site, die die Anfragen versendet, zustimmt, eine Referrer-Richtlinie von
no-referrer-when-downgrade
auf Element- oder Anfragebasis festzulegen. Nachteile: potenziell weniger Datenschutz für Benutzer vonsite-one.example
, möglicherweise nicht von allen Browsern unterstützt.
Schutz vor Cross-Site Request Forgery (CSRF) #
Beachten Sie, dass sich ein Sender einer Anfrage jederzeit entscheiden kann, keinen Referrer zu senden, indem er eine Richtlinie von no-referrer
festlegt (außerdem könnte ein böswilliger Akteur den Referrer sogar fälschen).
Verwenden Sie CSRF-Token als Ihren primären Schutz. Für zusätzliche Sicherheit sollten Sie SameSite nutzen und anstelle des Referer
-Headers Header wie den Origin
-Header (verfügbar bei POST- und CORS-Anfragen) sowie Sec-Fetch-Site
(falls verfügbar) verwenden.
Protokollierung #
Stellen Sie sicher, sich eventuell im Referer
befindende Benutzerdaten zu schützen.
Wenn Sie nur den Ursprungspunkt verwenden, prüfen Sie, ob der Origin
-Header eine Alternative sein könnte. Auf diese Weise erhalten Sie möglicherweise auf einfachere Weise die Informationen, die Sie zum Debuggen benötigen, ohne den Referrer analysieren zu müssen.
Zahlungen #
Zahlungsanbieter können für Sicherheitsüberprüfungen bei eingehenden Anfragen auf den Referer
-Header setzen.
Zum Beispiel:
- Der Nutzer klickt unter
online-shop.example/cart/checkout
auf einen Kaufen-Button. online-shop.example
leitet zum Verwalten der Transaktion aufpayment-provider.example
um.payment-provider.example
gleicht denReferer
dieser Anfrage mit einer Liste zulässigerReferer
-Werte ab, die von den Händlern eingerichtet wurde. Wenn er mit keinem Listeneintrag übereinstimmt, dann lehntpayment-provider.example
die Anfrage ab. Wenn es eine Übereinstimmung gibt, kann der Benutzer mit der Transaktion fortfahren.
Best Practices für Sicherheitsprüfungen bei Bezahlvorgängen #
Fazit: Als Zahlungsanbieter können Sie den Referer
als grundlegenden Überprüfungsfaktor zur Verhinderung naiver Angriffe verwenden – Sie sollten jedoch zusätzlich unbedingt eine andere, zuverlässigere Überprüfungsmethode einsetzen.
Der Referer
-Header alleine stellt keine zuverlässige Basis für eine Sicherheitsprüfung dar, denn die Site von der die Anfrage ausgeht, könnte unabhängig davon, ob es sich um einen legitimen Händler handelt oder nicht, eine no-referrer
-Richtlinie festgelegt haben, die die Referer
-Informationen vor dem Zahlungsanbieter zurückhält. Als Zahlungsanbieter kann Ihnen ein Blick auf den Referer
-Header jedoch zumindest dabei helfen naive Angreifer abzuwehren, die keine no-referrer
-Richtlinie festgelegt haben. Es bietet sich also an, den Referer
für eine erste grundlegende Sicherheitsprüfung zu nutzen. Sollten Sie dies tun, dann:
- Erwarten Sie nicht, dass der
Referer
immer verfügbar ist; und sollte er verfügbar sein, dann durchsuchen Sie ihn nur nach dem Minimum an möglichen enthaltenen Informationen, also nach der Origin. Wenn Sie die Liste mit erlaubtenReferer
-Werten festlegen, dann stellen Sie sicher, dass dort kein Pfad, sondern nur die Origin enthalten ist. Beispiel: Die erlaubtenReferer
-Werte füronline-shop.example
sollten die Angabeonline-shop.example
und nichtonline-shop.example/cart/checkout
beinhalten. Warum? Weil, wenn Sie entweder überhaupt keinenReferer
erwarten oder Sie einenReferer
-Wert erwarten, der der Origin der anfragestellenden Website entspricht, unerwartete Fehler vermieden werden können, da keine Vermutungen darüber angestellt werden müssen, welcheReferrer-Policy
von Ihrem Händler festgelegt wurde oder wie sich Browser verhalten könnten, wenn der Händler keine Richtlinie festgelegt hat. Sowohl die Site als auch der Browser könnten die Informationen des in der eingehenden Anfrage gesendetenReferers
auf die Origin beschränken oder denReferer
gar nicht senden. - Wenn der
Referer
vorhanden ist oder wenn er vorhanden ist und zusätzlich Ihre einfache Sicherheitsprüfung derReferer
-Origin erfolgreich war, können Sie den Benutzer zu einer weiteren zuverlässigeren Verifizierungsmethode weiterleiten (siehe unten).
Welche zuverlässigeren Verifizierungsmethoden gibt es?
Eine zuverlässige Verifizierungsmethode ist es, den Steller der Anfrage einen Hash der Anfrageparameter in Verbindung mit einem eindeutigen Schlüssel erstellen zu lassen. Sie können dann als Zahlungsanbieter auf Ihrer Seite den gleichen Hash berechnen und die Anfrage nur akzeptieren, wenn der Hash mit dem von Ihnen berechneten übereinstimmt.
Was passiert mit dem Referer
, wenn eine HTTP-Website eines Händlers ohne Referrer-Richtlinie Weiterleitungen zu einem HTTPS-Zahlungsanbieter durchführt?
In der Anfrage an den HTTPS-Zahlungsanbieter wird kein Referer
sichtbar sein, da die meisten Browser standardmäßig auf die Richtlinien strict-origin-when-cross-origin
oder no-referrer-when-downgrade
zurückgreifen, wenn eine Website keine Richtlinie festgelegt hat. Beachten Sie auch, dass Chromes Wechsel zur Verwendung einer neuen Standardrichtlinie dieses Verhalten nicht ändert.
Fazit #
Eine schützende Referrer-Richtlinie stellt eine großartige Möglichkeit dar, Ihren Benutzern mehr Privatsphäre zu bieten.
Um mehr über diverse Techniken zum Schutz Ihrer Benutzer zu erfahren, sehen Sie sich web.dev's Sammlung von Artikeln mit Sicherheitsbezug an!
Mit herzlichem Dank für Beiträge und Feedback an alle Rezensenten – insbesondere Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck und Kayce Basques.
Ressourcen #
- Verstehen von „Same-Site“ und „Same-Origin“
- Ein neuer Sicherheitsheader: Referrer-Richtlinie (2017)
- „Referrer-Richtlinie“ auf MDN
- „Referer-Header: Datenschutz- und Sicherheitsbedenken“ bei MDN
- Chrome-Änderung: Blink – Implementierungsabsicht
- Chrome-Änderung: Blink – Auslieferungsabsicht
- Chrome-Aktualisierung: Statuseintrag
- Chrome-Aktualisierung: Blogpost zur 85 Beta
- GitHub-Thread zum Kürzen von Refferern: Wie sich verschiedene Browser verhalten
- Referrer-Richtlinien-Spezifikation