Best Practices für Verweis-URLs und Referrer-URL-Richtlinien

Maud Nalpas

Auf dieser Seite werden einige Best Practices für das Festlegen der Referrer-Policy und die Verwendung des Referrers in eingehenden Anfragen beschrieben.

Zusammenfassung

• Unerwartete Informationslecks zwischen verschiedenen Quellen schaden der Privatsphäre von Webnutzern. Eine restriktive Referrer-Richtlinie kann helfen.
• Legen Sie eine Verweisrichtlinie von strict-origin-when-cross-origin fest. So bleibt der Nutzen des Referrers weitgehend erhalten, während gleichzeitig das Risiko verringert wird, dass Daten über verschiedene Ursprünge hinweg weitergegeben werden.
• Verwenden Sie keine Referrer zum Schutz vor Cross-Site Request Forgery (CSRF). Verwenden Sie stattdessen CSRF-Tokens und andere Header als zusätzliche Sicherheitsebene.

Referer und Referrer-Policy – Grundlagen

HTTP-Anfragen können einen optionalen Referer-Header enthalten, der den Ursprung oder die URL der Webseite angibt, von der die Anfrage stammt. Mit dem Referrer-Policy-Header wird festgelegt, welche Daten im Referer-Header verfügbar sind.

Im folgenden Beispiel enthält der Referer-Header die vollständige URL der Seite auf site-one, von der die Anfrage gesendet wurde.

Der Referer-Header kann in verschiedenen Arten von Anfragen vorhanden sein:

• Navigationsanfragen, wenn ein Nutzer auf einen Link klickt.
• Anfragen für untergeordnete Ressourcen, wenn ein Browser Bilder, iFrames, Skripts und andere Ressourcen anfordert, die eine Seite benötigt.

Bei Navigationsvorgängen und iFrames können Sie mit JavaScript auch über document.referrer auf diese Daten zugreifen.

Aus Referer-Werten lässt sich viel lernen. Ein Analysedienst könnte damit beispielsweise ermitteln, dass 50% der Besucher auf site-two.example von social-network.example kamen. Wenn die vollständige URL, einschließlich des Pfads und des Abfragestrings, im Referer über Ursprünge hinweg gesendet wird, kann dies jedoch den Datenschutz der Nutzer gefährden und Sicherheitsrisiken mit sich bringen:

Die URLs 1 bis 5 enthalten private und manchmal vertrauliche oder identifizierbare Informationen. Wenn diese Informationen ohne Wissen des Nutzers über verschiedene Ursprünge hinweg weitergegeben werden, kann dies die Privatsphäre von Webnutzern gefährden.

URL 6 ist eine Funktions-URL. Wenn jemand anderes als der beabsichtigte Nutzer diese E‑Mail erhält, kann ein böswilliger Akteur die Kontrolle über das Konto dieses Nutzers übernehmen.

Wenn Sie einschränken möchten, 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. Je nach Richtlinie können die Daten, die über den Referer-Header (und document.referrer) verfügbar sind, Folgendes sein:

• Keine Daten (keine Referer-Kopfzeile vorhanden)
• Nur der Ursprung
• Die vollständige URL: Ursprung, Pfad und Abfragestring

Einige Richtlinien sind so konzipiert, dass sie sich je nach Kontext unterschiedlich verhalten: ursprungsübergreifende oder ursprungsbezogene Anfrage, ob das Ziel der Anfrage so sicher wie der Ursprung ist oder beides. Das ist nützlich, um die Menge an Informationen zu begrenzen, die zwischen Ursprüngen oder mit weniger sicheren Ursprüngen geteilt werden, während die Referrer-Informationen auf Ihrer eigenen Website erhalten bleiben.

In der folgenden Tabelle sehen Sie, wie Referrer-Richtlinien die URL-Daten einschränken, die über den Referer-Header und document.referrer verfügbar sind:

Auf MDN finden Sie eine vollständige Liste der Richtlinien und Verhaltensbeispiele.

Beachten Sie beim Festlegen einer Referrer-Richtlinie Folgendes:

• Bei allen Richtlinien, die das Schema (HTTPS im Vergleich zu HTTP) berücksichtigen (strict-origin, no-referrer-when-downgrade und strict-origin-when-cross-origin), werden Anfragen von einem HTTP-Ursprung zu einem anderen HTTP-Ursprung genauso behandelt wie Anfragen von einem HTTPS-Ursprung zu einem anderen HTTPS-Ursprung, obwohl HTTP weniger sicher ist. Das liegt daran, dass es bei diesen Richtlinien darum geht, ob ein Sicherheits-Downgrade stattfindet, d. h., ob die Anfrage Daten von einem verschlüsselten Ursprung an einen unverschlüsselten Ursprung weitergeben kann, wie bei HTTPS-→HTTP-Anfragen. Eine HTTP-→ HTTP-Anfrage ist vollständig unverschlüsselt, es gibt also kein Downgrade.
• Wenn eine Anfrage vom selben Ursprung stammt, ist das Schema (HTTPS oder HTTP) dasselbe. Es gibt also keine Sicherheitsbeeinträchtigung.

Standard-Verweisrichtlinien in Browsern

Stand Oktober 2021

Wenn keine Verweisrichtlinie festgelegt ist, verwendet der Browser seine Standardrichtlinie.

Best Practices für das Festlegen der Referrer-Richtlinie

Es gibt verschiedene Möglichkeiten, Referrer-Richtlinien für Ihre Website festzulegen:

• Als HTTP-Header
• Im HTML-Code
• Von JavaScript aus pro Anfrage

Sie können verschiedene Richtlinien für verschiedene Seiten, Anfragen oder Elemente festlegen.

Sowohl der HTTP-Header als auch das Meta-Element sind auf Seitenebene. Die Prioritätsreihenfolge für die Bestimmung der effektiven Richtlinie eines Elements ist wie folgt:

1. Richtlinie auf Elementebene
2. Richtlinie auf Seitenebene
3. Browserstandard

Beispiel:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Das Bild wird mit einer no-referrer-when-downgrade-Richtlinie angefordert und alle anderen Subressourcenanfragen von dieser Seite folgen der strict-origin-when-cross-origin-Richtlinie.

Referrer-Richtlinie ansehen

Auf securityheaders.com können Sie ganz einfach herausfinden, welche Richtlinie für eine bestimmte Website oder Seite verwendet wird.

Sie können auch die Entwicklertools in Chrome, Edge oder Firefox verwenden, um die für eine bestimmte Anfrage verwendete Referrer-Richtlinie zu sehen. Zum Zeitpunkt der Erstellung dieses Dokuments wird in Safari der Referrer-Policy-Header nicht angezeigt, aber der gesendete Referer.

Welche Richtlinie sollten Sie für Ihre Website festlegen?

Wir empfehlen dringend, eine datenschutzfreundliche Richtlinie wie strict-origin-when-cross-origin (oder strikter) explizit festzulegen.

Warum „explizit“?

Wenn Sie keine Verweisrichtlinie festlegen, wird die Standardrichtlinie des Browsers verwendet. Tatsächlich greifen Websites häufig auf die Standardeinstellung des Browsers zurück. Das ist jedoch nicht ideal, weil:

• Verschiedene Browser haben unterschiedliche Standardrichtlinien. Wenn Sie sich also auf Browserstandards verlassen, verhält sich Ihre Website in den verschiedenen Browsern nicht vorhersagbar.
• 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 datenschutzfreundliche Richtlinie entscheiden, bevor sich die Browserstandardeinstellungen ändern, haben Sie die Kontrolle und können Tests nach Bedarf durchführen.

Warum strict-origin-when-cross-origin (oder strenger)?

Sie benötigen eine Richtlinie, die sicher, datenschutzfreundlich und nützlich ist. Was „nützlich“ bedeutet, hängt davon ab, was Sie vom Referrer erwarten:

• Sicher: Wenn Ihre Website HTTPS verwendet (falls nicht, sollten Sie das so schnell wie möglich ändern), sollten die URLs Ihrer Website nicht in Nicht-HTTPS-Anfragen preisgegeben werden. Da jeder im Netzwerk diese sehen kann, würden Lecks Ihre Nutzer Man-in-the-Middle-Angriffen aussetzen. Die Richtlinien no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer und strict-origin lösen dieses Problem.
• Datenschutzfreundlich: Bei einer anfrageübergreifenden Anfrage wird mit no-referrer-when-downgrade die vollständige URL freigegeben, was zu Datenschutzproblemen führen kann. strict-origin-when-cross-origin und strict-origin geben nur den Ursprung weiter und no-referrer gibt überhaupt nichts weiter. Es bleiben die datenschutzfreundlichen Optionen strict-origin-when-cross-origin, strict-origin und no-referrer.
• Nützlich: no-referrer und strict-origin geben niemals die vollständige URL weiter, auch nicht bei Anfragen mit demselben Ursprung. Wenn Sie die vollständige URL benötigen, ist strict-origin-when-cross-origin die bessere Option.

strict-origin-when-cross-origin ist also in der Regel eine sinnvolle Wahl.

Beispiel: strict-origin-when-cross-origin-Richtlinie festlegen

index.html:

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

Oder serverseitig, z. B. in Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Was passiert, wenn strict-origin-when-cross-origin (oder strenger) nicht alle Ihre Anwendungsfälle abdeckt?

In diesem Fall sollten Sie schrittweise vorgehen: Legen Sie eine restriktive Richtlinie wie strict-origin-when-cross-origin für Ihre Website fest und bei Bedarf eine weniger restriktive Richtlinie für bestimmte Anfragen oder HTML-Elemente.

Beispiel: Richtlinie auf 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>

Safari/WebKit kann den document.referrer- oder den Referer-Header für Cross-Site-Anfragen begrenzen. Weitere Informationen

Beispiel: Richtlinie auf Anfrageebene

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Was sollten Sie noch beachten?

Ihre Richtlinie sollte von Ihrer Website und Ihren Anwendungsfällen abhängen, die von Ihnen, Ihrem Team und Ihrem Unternehmen festgelegt werden. Wenn einige URLs personenbezogene oder sensible Daten enthalten, legen Sie eine Schutzrichtlinie fest.

Best Practices für eingehende Anfragen

Hier finden Sie einige Richtlinien für den Fall, dass auf Ihrer Website die Verweis-URL eingehender Anfragen verwendet wird.

Nutzerdaten schützen

Die Referer kann private, personenbezogene oder identifizierbare Daten enthalten. Behandeln Sie sie daher entsprechend.

Eingehende Referrer-URLs können sich ändern {referer-can-change}

Die Verwendung des Referrers aus eingehenden anfrageübergreifenden Anfragen unterliegt einigen Einschränkungen:

• Wenn Sie keine Kontrolle über die Implementierung des Anfragestellers haben, können Sie keine Annahmen über den Referer-Header (und document.referrer) treffen, den Sie erhalten. Der Anfragesteller kann jederzeit zu einer no-referrer-Richtlinie oder allgemein zu einer strengeren Richtlinie als bisher wechseln. Das bedeutet, dass Sie weniger Daten von Referer erhalten als zuvor.
• Browser verwenden immer häufiger standardmäßig die Referrer-Policy strict-origin-when-cross-origin. Das bedeutet, dass Sie bei eingehenden ursprungsübergreifenden Anfragen möglicherweise nur noch den Ursprung anstelle einer vollständigen Referrer-URL erhalten, wenn auf der Absenderwebsite keine Richtlinie festgelegt ist.
• Browser können die Art und Weise ändern, wie sie Referer verwalten. Einige Browserentwickler entscheiden sich möglicherweise dafür, Referrer bei quellenübergreifenden Unterressourcenanfragen immer auf Ursprünge zu beschränken, um den Datenschutz zu verbessern.
• Der Header Referer (und document.referrer) enthält möglicherweise mehr Daten als Sie benötigen. Beispiel: Die URL ist möglicherweise vollständig, obwohl Sie nur wissen möchten, ob die Anfrage ursprungsübergreifend ist.

Alternativen zu Referer

Möglicherweise müssen Sie Alternativen in Betracht ziehen, wenn:

• Eine wichtige Funktion Ihrer Website verwendet die Referrer-URL eingehender anfrageübergreifender Anfragen.
• Ihre Website empfängt nicht mehr den Teil der Referrer-URL, der für eine ursprungsübergreifende Anfrage erforderlich ist. Dies geschieht, wenn der Anforderungs-Emitter seine Richtlinie ändert oder wenn keine Richtlinie festgelegt ist und sich die Richtlinie des Browserstandards ändert (wie in Chrome 85).

Um Alternativen zu definieren, müssen Sie zuerst analysieren, welchen Teil des Referrers Sie verwenden.

Wenn Sie nur den Ursprung benötigen

• Wenn Sie den Referrer in einem Skript verwenden, das Zugriff auf die oberste Ebene der Seite hat, ist window.location.origin eine Alternative.
• Falls verfügbar, enthalten Header wie Origin und Sec-Fetch-Site die Origin oder beschreiben, ob die Anfrage ursprungsübergreifend ist. Das ist möglicherweise genau das, was Sie benötigen.

Wenn Sie andere Elemente der URL benötigen (Pfad, Suchparameter usw.)

• Anfrageparameter sind möglicherweise für Ihren Anwendungsfall geeignet, sodass Sie den Referrer nicht parsen müssen.
• Wenn Sie den Referrer in einem Skript verwenden, das Zugriff auf die oberste Ebene der Seite hat, kann window.location.pathname eine Alternative sein. Extrahieren Sie nur den Pfadabschnitt der URL und übergeben Sie ihn als Argument, damit keine potenziell vertraulichen Informationen in den URL-Parametern weitergegeben werden.

Wenn Sie diese Alternativen nicht nutzen können:

• Prüfen Sie, ob Sie Ihre Systeme so ändern können, dass der Anforderungs-Emitter (z. B. site-one.example) die benötigten Informationen explizit in einer Konfiguration festlegt.
  • Vorteile: expliziter, datenschutzfreundlicher für site-one.example-Nutzer, zukunftssicherer.
  • Nachteil: Möglicherweise mehr Arbeit für Sie oder die Nutzer Ihres Systems.
• Prüfen Sie, ob die Website, von der die Anfragen ausgehen, bereit ist, eine Referrer-Richtlinie von no-referrer-when-downgrade pro Element oder pro Anfrage festzulegen.
  • Nachteil: Möglicherweise weniger datenschutzfreundlich für site-one.example-Nutzer, wird möglicherweise nicht in allen Browsern unterstützt.

Schutz vor websiteübergreifender Anfragefälschung (Cross-Site Request Forgery, CSRF)

Ein Anforderungs-Emitter kann immer entscheiden, den Referrer nicht zu senden, indem er eine no-referrer-Richtlinie festlegt. Ein böswilliger Akteur könnte den Referrer sogar fälschen.

Verwenden Sie CSRF-Tokens als primären Schutz. Für zusätzlichen Schutz sollten Sie SameSite verwenden und anstelle von Referer Header wie Origin (verfügbar für POST- und CORS-Anfragen) und Sec-Fetch-Site verwenden, sofern verfügbar.

Protokollieren und debuggen

Achten Sie darauf, dass personenbezogene oder sensible Daten von Nutzern, die sich möglicherweise in der Referer befinden, geschützt werden.

Wenn Sie nur den Ursprung verwenden, prüfen Sie, ob Sie stattdessen den Header Origin verwenden können. So erhalten Sie möglicherweise auf einfachere Weise die Informationen, die Sie für das Debugging benötigen, ohne den Referrer parsen zu müssen.

Zahlungen

Zahlungsanbieter verlassen sich möglicherweise auf den Referer-Header eingehender Anfragen für Sicherheitsprüfungen.

Beispiel:

• Der Nutzer klickt auf online-shop.example/cart/checkout auf die Schaltfläche Kaufen.
• online-shop.example leitet weiter zu payment-provider.example, um die Transaktion zu verwalten.
• Bei payment-provider.example wird die Referer dieser Anfrage mit einer Liste der zulässigen Referer-Werte verglichen, die von den Händlern eingerichtet wurden. Wenn sie mit keinem Eintrag in der Liste übereinstimmt, lehnt payment-provider.example die Anfrage ab. Wenn die Angaben übereinstimmen, kann der Nutzer mit der Transaktion fortfahren.

Best Practices für Sicherheitsprüfungen des Zahlungsablaufs

Als Zahlungsanbieter können Sie Referer als grundlegende Sicherheitsmaßnahme gegen bestimmte Angriffe verwenden. Der Referer-Header allein ist jedoch keine zuverlässige Grundlage für eine Prüfung. Die anfragende Website, unabhängig davon, ob es sich um einen legitimen Händler handelt oder nicht, kann eine no-referrer-Richtlinie festlegen, die die Referer-Informationen für den Zahlungsanbieter nicht verfügbar macht.

Die Referer kann Zahlungsanbietern helfen, naive Angreifer zu erkennen, die keine no-referrer-Richtlinie festgelegt haben. Wenn Sie das Referer als ersten Check verwenden:

• Erwarte nicht, dass Referer immer vorhanden ist. Wenn sie vorhanden ist, vergleichen Sie sie nur mit den Mindestdaten, die sie enthalten kann, nämlich dem Ursprung.
  • Wenn Sie die Liste der zulässigen Referer-Werte festlegen, geben Sie nur den Ursprung und keinen Pfad an.
  • Die zulässigen Referer-Werte für online-shop.example sollten beispielsweise online-shop.example und nicht online-shop.example/cart/checkout sein. Wenn Sie entweder gar kein Referer oder einen Referer-Wert erwarten, der nur den Ursprung der anfragenden Website enthält, vermeiden Sie Fehler, die durch Annahmen zum Referrer-Policy des Händlers entstehen können.
• Wenn das Referer fehlt oder vorhanden ist und die grundlegende Referer-Ursprungsprüfung erfolgreich ist, können Sie zu einer anderen, zuverlässigeren Bestätigungsmethode wechseln.

Damit Zahlungen zuverlässiger überprüft werden können, sollte der Anfragesteller die Anfrageparameter mit einem eindeutigen Schlüssel hashen. Zahlungsanbieter können dann denselben Hash auf Ihrer Seite berechnen und die Anfrage nur akzeptieren, wenn sie mit Ihrer Berechnung übereinstimmt.

Was passiert mit dem Referer, wenn eine HTTP-Händlerwebsite ohne Referrer-Richtlinie zu einem HTTPS-Zahlungsanbieter weiterleitet?

In der Anfrage an den HTTPS-Zahlungsanbieter ist kein Referer zu sehen, da die meisten Browser standardmäßig strict-origin-when-cross-origin oder no-referrer-when-downgrade verwenden, wenn für eine Website keine Richtlinie festgelegt ist. Die Änderung der Standardrichtlinie in Chrome ändert nichts an diesem Verhalten.

Fazit

Eine restriktive Referrer-Richtlinie ist eine gute Möglichkeit, die Privatsphäre Ihrer Nutzer zu schützen.

Weitere Informationen zu verschiedenen Techniken zum Schutz Ihrer Nutzer finden Sie in unserer Sammlung Sicher und geschützt.

Ressourcen

• „Same-Site“ und „Same-Origin“
• Ein neuer Sicherheitsheader: Referrer Policy (2017)
• Referrer-Policy auf MDN
• Referer-Header: Bedenken zu Datenschutz und Sicherheit auf MDN
• Chrome-Änderung: Blink-Intention zur Implementierung
• Chrome-Änderung: Blink-Intention zum Ausliefern
• Chrome-Änderung: Statuseintrag
• Chrome-Änderung: Blogpost zur Betaversion 85
• GitHub-Thread zum Kürzen von Referrern: Was verschiedene Browser tun
• Referrer-Policy-Spezifikation

Vielen Dank an alle Rezensenten für ihre Beiträge und ihr Feedback, insbesondere an Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck und Kayce Basques.