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

Best Practices zum Festlegen Ihrer Referrer-Policy und zur Verwendung der Referrer-URL in eingehenden Anfragen.

Maud Nalpas
Maud Nalpas

Zusammenfassung

  • Unerwartetes ursprungsübergreifendes Datenlecks beeinträchtigt den Datenschutz für Webnutzer. Eine schützende Verweis-URL kann dabei Abhilfe schaffen.
  • Legen Sie gegebenenfalls die Verweisrichtlinie „strict-origin-when-cross-origin“ fest. Dabei bleibt ein großer Teil der Nützlichkeit der Verweis-URL erhalten, während gleichzeitig das Risiko von ursprungsübergreifenden Datenlecks verringert wird.
  • Verwenden Sie keine Verweis-URLs für den CSRF-Schutz (Cross-Site Request Forgery). Verwenden Sie stattdessen CSRF-Tokens und andere Header als zusätzliche Sicherheitsebene.

Erste Schritte mit Verweis- und Referrer-URL-Richtlinie

HTTP-Anfragen können den optionalen Referer-Header enthalten, der den Ursprung oder die Webseiten-URL der Anfrage angibt. Mit dem Referrer-Policy-Header wird definiert, welche Daten im Referer-Header verfügbar gemacht werden.

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

HTTP-Anfrage mit einem Verweis-Header

Der Referer-Header kann in verschiedenen Anfragetypen vorhanden sein:

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

Bei Navigationen und iFrames kann mit document.referrer auch über JavaScript auf diese Daten zugegriffen werden.

Der Wert Referer kann aufschlussreich sein. Beispielsweise könnte ein Analysedienst anhand des Werts ermitteln, dass 50% der Besucher auf site-two.example von social-network.example kommen.

Wenn jedoch die vollständige URL einschließlich Pfad und Abfragestring im Referer ursprungsübergreifend gesendet wird, kann dies den Datenschutz behindern und Sicherheitsrisiken darstellen. Sehen Sie sich diese URLs an:

URLs mit Pfaden, die verschiedenen Datenschutz- und Sicherheitsrisiken zugeordnet sind

Die URLs 1 bis 5 enthalten private Informationen, manchmal sogar personenidentifizierbare oder vertrauliche Informationen. Wenn sie unbemerkt von verschiedenen Ursprüngen weitergegeben werden, kann das den Datenschutz für Webnutzer gefährden.

URL 6 ist eine Funktions-URL. Sie sollten nicht in die Hände anderer Personen gelangen als der beabsichtigten. In diesem Fall könnte ein böswilliger Akteur das Konto dieses Nutzers hacken.

Mit einer Verweis-URL-Richtlinie können Sie einschränken, welche Verweisdaten für Anfragen von Ihrer Website zur Verfügung gestellt werden.

Welche Richtlinien sind verfügbar und worin unterscheiden sie sich?

Sie können eine von acht Richtlinien auswählen. Abhängig von der Richtlinie können im Referer-Header (und document.referrer) folgende Daten verfügbar sein:

  • Keine Daten (kein Referer-Header vorhanden)
  • Nur origin
  • Die vollständige URL: Ursprung, Pfad und Abfragestring
Daten, die im Verweis-Header und in „document.referrer“ enthalten sein können.

Einige Richtlinien verhalten sich je nach Kontext unterschiedlich: ursprungsübergreifende oder Same-Origin-Anfrage, Sicherheit (ob das Anfrageziel so sicher wie der Ursprung ist) oder beides. Dies ist nützlich, um die Menge der Informationen zu begrenzen, die zwischen verschiedenen Quellen oder auf weniger sichere Ursprünge weitergegeben werden. Gleichzeitig bleibt die Aussagekraft der Referrer-URL in Ihrer eigenen Website erhalten.

In der folgenden Übersicht sehen Sie, wie Verweis-URLs die über den Verweis-Header und document.referrer verfügbaren URL-Daten einschränken:

Unterschiedliche Verweisrichtlinien und deren Verhalten je nach Sicherheits- und ursprungsübergreifendem Kontext

MDN bietet eine vollständige Liste mit Beispielen für Richtlinien und Verhalten.

Hinweise:

  • Alle Richtlinien, die das Schema (HTTPS oder HTTP) berücksichtigen (strict-origin, no-referrer-when-downgrade und strict-origin-when-cross-origin), behandeln Anfragen von einem HTTP-Ursprung an einen anderen HTTP-Ursprung genauso wie Anfragen von einem HTTPS-Ursprung zu einem anderen HTTPS-Ursprung, auch wenn HTTP weniger sicher ist. Das liegt daran, dass für diese Richtlinien wichtig ist, ob ein Sicherheitsherabstufung erfolgt, d.h. ob die Anfrage Daten von einem verschlüsselten Ursprung an einen unverschlüsselten Ursprung weitergeben kann. Eine HTTP → HTTP-Anfrage ist durchgehend unverschlüsselt, es gibt also kein Downgrade. HTTPS → HTTP-Anfragen stellen im Gegenteil ein Downgrade dar.
  • Wenn eine Anfrage same-origin ist, ist das Schema (HTTPS oder HTTP) identisch und es gibt kein Sicherheitsdowngrade.

Standard-Referrer-URL-Richtlinien in Browsern

Stand: Oktober 2021

Wenn keine Verweisrichtlinie festgelegt ist, wird die Standardrichtlinie des Browsers verwendet.

Browser Standard-Referrer-Policy / Verhalten
Chrome Der Standardwert ist strict-origin-when-cross-origin.
Firefox Der Standardwert ist strict-origin-when-cross-origin.
Ab Version 93 für Nutzer des strikten Tracking-Schutzes und des privaten Surfens: Die weniger restriktiven Richtlinien für Referrer-URLs no-referrer-when-downgrade, origin-when-cross-origin und unsafe-url werden bei websiteübergreifenden Anfragen ignoriert. Das bedeutet, dass die Referrer-URL bei websiteübergreifenden Anfragen immer gekürzt wird – unabhängig von der Websiterichtlinie.
Edge Der Standardwert ist strict-origin-when-cross-origin.
Safari Die Standardeinstellung ähnelt strict-origin-when-cross-origin, hat aber einige Besonderheiten. Weitere Informationen findest du unter Tracking verhindern.

Verweis-URL festlegen: Best Practices

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

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

Der HTTP-Header und das Meta-Element befinden sich beide auf Seitenebene. Die Rangfolge bei der Bestimmung der geltenden Richtlinie eines Elements lautet:

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

Example:

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, während alle anderen Unterressourcenanfragen von dieser Seite der Richtlinie strict-origin-when-cross-origin folgen.

Wie kann ich die Verweis-URL-Richtlinie aufrufen?

securityheaders.com ist praktisch, um die Richtlinie zu ermitteln, die auf einer bestimmten Website oder Seite verwendet wird.

Sie können auch die Entwicklertools von Chrome, Edge oder Firefox verwenden, um die Verweis-URL-Richtlinie für eine bestimmte Anfrage anzuzeigen. Zum Zeitpunkt der Veröffentlichung dieser Informationen wird in Safari der Referrer-Policy-Header nicht angezeigt, wohl aber das gesendete Referer.

Screenshot des Bereichs „Network“ der Chrome-Entwicklertools mit Verweis „Referrer-URL“ und Referrer-Policy.
Chrome-Entwicklertools, Bereich Netzwerk mit ausgewählter Anfrage.

Welche Richtlinie sollten Sie für Ihre Website festlegen?

Zusammenfassung: Legen Sie ausdrücklich eine datenschutzfreundliche Richtlinie wie strict-origin-when-cross-origin fest (oder strenger).

Warum „explizit“?

Wenn keine Verweis-URL festgelegt ist, wird die Standardrichtlinie des Browsers verwendet. Websites wenden sich häufig an die Standardrichtlinie des Browsers. Das ist jedoch nicht ideal, denn:

  • Die Standardrichtlinien des Browsers sind entweder no-referrer-when-downgrade, strict-origin-when-cross-origin oder strenger – je nach Browser und Modus (privat/Inkognitomodus). Ihre Website funktioniert daher in verschiedenen Browsern nicht vorhersehbar.
  • Browser verwenden strengere Standardeinstellungen wie strict-origin-when-cross-origin und Mechanismen wie das Zuschneiden von Verweis-URLs für ursprungsübergreifende Anfragen. Wenn Sie ausdrücklich eine datenschutzfreundliche Richtlinie aktivieren, bevor die Standardeinstellungen des Browsers geändert werden, können Sie selbst entscheiden und Tests 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 von der Referrer-URL erwarten:

  • Sicher: Wenn Ihre Website HTTPS verwendet (wenn nicht, sollte es priorisiert werden), möchten Sie nicht, dass die URLs Ihrer Website bei Nicht-HTTPS-Anfragen offengelegt werden. Da sie für jeden im Netzwerk sichtbar sind, werden Ihre Nutzer Personen-in-the-Middle-Angriffen ausgesetzt. Die Richtlinien no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer und strict-origin lösen dieses Problem.
  • Datenschutz verbessern: Bei einer ursprungsübergreifenden Anfrage gibt no-referrer-when-downgrade die vollständige URL weiter. Der Datenschutz trägt nicht dazu bei. strict-origin-when-cross-origin und strict-origin teilen sich nur den Ursprung und no-referrer teilt überhaupt nichts. Ihnen stehen dann strict-origin-when-cross-origin, strict-origin und no-referrer als datenschutzfreundliche Optionen zur Verfügung.
  • Nützlich: no-referrer und strict-origin teilen nie die vollständige URL, auch nicht bei Anfragen desselben Ursprungs. In diesem Fall ist strict-origin-when-cross-origin die bessere Option.

All das bedeutet, dass strict-origin-when-cross-origin im Allgemeinen eine vernünftige Wahl ist.

Beispiel: Festlegen einer strict-origin-when-cross-origin-Richtlinie:

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 ist, wenn strict-origin-when-cross-origin (oder strengere Regeln) nicht alle Ihre Anwendungsfälle abdeckt?

Gehen Sie in diesem Fall schrittweise vor: Legen Sie eine Schutzrichtlinie wie strict-origin-when-cross-origin für Ihre Website und bei Bedarf eine strengere Richtlinie für bestimmte Anfragen oder HTML-Elemente fest.

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 document.referrer oder den Referer-Header für websiteübergreifende Anfragen begrenzen. Siehe Details.

Beispiel: Richtlinie auf Anfrageebene

script.js:

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

Was sollten Sie noch beachten?

Ihre Richtlinien sollten von Ihrer Website und Anwendungsfällen abhängen – dies liegt bei Ihnen, Ihrem Team und Ihrem Unternehmen. Wenn einige URLs personenidentifizierbare oder sensible Daten enthalten, legen Sie eine Schutzrichtlinie fest.

Referrer-URL aus eingehenden Anfragen verwenden: Best Practices

Was ist zu tun, wenn die Funktionalität Ihrer Website die Verweis-URL eingehender Anfragen verwendet?

Nutzerdaten schützen

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

Beachten Sie, dass sich die Referer, die Sie erhalten, ändern können

Bei der Verwendung der Referrer-URL aus eingehenden ursprungsübergreifenden Anfragen gelten einige Einschränkungen:

  • Wenn Sie keine Kontrolle über die Implementierung des Anfragesenders haben, können Sie keine Annahmen zum Referer-Header (und document.referrer) treffen, den Sie erhalten. Der Anfragenaussteller kann jederzeit entscheiden, ob er zu einer no-referrer-Richtlinie oder allgemeiner zu einer strikteren Richtlinie als zuvor wechselt. Dadurch erhalten Sie weniger Daten über die Referer als früher.
  • Browser verwenden standardmäßig zunehmend die Verweis-URL-Richtlinie strict-origin-when-cross-origin. Das bedeutet, dass Sie in eingehenden ursprungsübergreifenden Anfragen jetzt möglicherweise nur den Ursprung (anstelle der vollständigen Verweis-URL) erhalten, wenn für die Website, die diese sendet, keine Richtlinie festgelegt ist.
  • Browser können die Verwaltung von Referer ändern. Zukünftig haben sie beispielsweise die Möglichkeit, Verweis-URLs bei ursprungsübergreifenden Unterressourcenanfragen aus Datenschutzgründen immer auf die Ursprünge zu kürzen.
  • Der Referer-Header (und document.referrer) können mehr Daten enthalten als erforderlich, z. B. eine vollständige URL, wenn Sie nur wissen möchten, ob die Anfrage ursprungsübergreifend ist.

Alternativen zu Referer

In folgenden Fällen müssen Sie möglicherweise Alternativen in Betracht ziehen:

  • Für eine grundlegende Funktion Ihrer Website wird die Verweis-URL eingehender ursprungsübergreifender Anfragen verwendet.
  • und/oder wenn Ihre Website den Teil der Verweis-URL, den sie für eine ursprungsübergreifende Anfrage benötigt, nicht mehr erhält. Dies geschieht, wenn der Absender der Anfrage seine Richtlinie geändert hat oder wenn keine Richtlinie festgelegt und die Richtlinie der Standardeinstellung des Browsers geändert wurde (wie in Chrome 85).

Analysieren Sie zum Definieren von Alternativen zunächst, welchen Teil der Referrer-URL Sie verwenden.

Wenn Sie nur den Ursprung (https://site-one.example) benötigen:

  • Wenn Sie die Referrer-URL in einem Skript mit Top-Level-Zugriff auf die Seite verwenden, ist window.location.origin eine Alternative.
  • Sofern verfügbar, geben Header wie Origin und Sec-Fetch-Site den Origin oder beschreiben, ob die Anfrage ursprungsübergreifend ist, was möglicherweise genau das ist, was Sie benötigen.

Wenn Sie andere Elemente der URL benötigen (z. B. Pfad oder Suchparameter):

  • Anfrageparameter können für Ihren Anwendungsfall relevant sein. Dies erspart Ihnen die Arbeit, die Referrer-URL zu parsen.
  • Wenn Sie die Referrer-URL in einem Skript mit Top-Level-Zugriff auf die Seite verwenden, kann window.location.pathname eine Alternative sein. Extrahieren Sie nur den Pfadabschnitt der URL und übergeben Sie ihn als Argument, damit potenziell vertrauliche Informationen in den URL-Parametern nicht weitergegeben werden.

Wenn Sie keine dieser Alternativen verwenden können:

  • Prüfen Sie, ob Ihre Systeme so geändert werden können, dass der Sender der Anfrage (site-one.example) die benötigten Informationen in einer Konfiguration irgendeiner Art explizit festlegt. Pro: expliziter, datenschutzfreundlicher für site-one.example-Nutzer und zukunftssicherer. Nachteil: Mehr Arbeit von Ihrer Seite oder für die Nutzenden Ihres Systems.
  • Prüfen Sie, ob die Website, die die Anfragen ausgibt, möglicherweise stimmt, dass die Verweis-URL pro Element oder pro Anfrage auf no-referrer-when-downgrade festgelegt wird. Nachteil: potenziell weniger datenschutzfreundlich für site-one.example-Nutzer, wird möglicherweise nicht in allen Browsern unterstützt.

Cross-Site Request Forgery-Schutz (CSRF)

Beachten Sie, dass ein Anfragenaussteller immer entscheiden kann, die Referrer-URL nicht zu senden, indem er eine no-referrer-Richtlinie festlegt. Ein böswilliger Akteur könnte sogar die Referrer-URL per Spoofing ausspionieren.

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

Logging

Achte darauf, die personenbezogenen oder sensiblen Daten von Nutzern zu schützen, die sich möglicherweise im Referer befinden.

Wenn Sie nur den Ursprung verwenden, prüfen Sie, ob der Header Origin eine Alternative sein könnte. Dadurch erhalten Sie möglicherweise die Informationen, die Sie für die Fehlerbehebung benötigen, einfacher und ohne die Referrer-URL parsen zu müssen.

Zahlungen

Zahlungsdienstleister können für Sicherheitsprüfungen den Referer-Header eingehender Anfragen nutzen.

Beispiel:

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

Best Practices für Sicherheitsprüfungen für den Zahlungsfluss

Zusammenfassung: Als Zahlungsdienstleister können Sie Referer als einfache Prüfung auf naive Angriffe verwenden. Sie sollten aber unbedingt eine andere, zuverlässigere Bestätigungsmethode nutzen.

Der Referer-Header allein ist keine zuverlässige Grundlage für eine Prüfung: Die anfragende Website kann eine no-referrer-Richtlinie festlegen, damit der Zahlungsanbieter die Referer-Informationen nicht mehr erhält. Als Zahlungsanbieter kann es jedoch helfen, sich die Referer anzusehen, um naive Angreifer abzufangen, die keine no-referrer-Richtlinie festgelegt haben. Sie können also Referer als erste einfache Prüfung verwenden. Gehen Sie dabei so vor:

  • Erwarten Sie nicht, dass Referer immer vorhanden ist. Wenn sie vorhanden ist, prüfen Sie nur die Daten, die mindestens enthalten sind: den Ursprung. Beim Festlegen der Liste der zulässigen Referer-Werte darf kein Pfad enthalten sein, sondern nur der Ursprung. Beispiel: Die zulässigen Referer-Werte für online-shop.example sollten online-shop.example sein, nicht online-shop.example/cart/checkout. Warum? Wenn du entweder gar kein Referer oder einen Referer-Wert erwartest, der der Ursprung der anfragenden Website ist, vermeidest du unerwartete Fehler, da du keine Annahmen über die vom Händler festgelegte Referrer-Policy oder das Verhalten des Browsers annimmst, wenn er keine Richtlinien festgelegt hat. Sowohl die Website als auch der Browser können das in der eingehenden Anfrage an den Ursprung gesendete Referer entfernen oder das Referer gar nicht senden.
  • Wenn Referer fehlt oder vorhanden ist und Ihre grundlegende Referer-Ursprungsprüfung erfolgreich war, können Sie zu Ihrer anderen, zuverlässigeren Bestätigungsmethode wechseln (siehe unten).

Was ist die zuverlässigere Bestätigungsmethode?

Eine zuverlässige Bestätigungsmethode besteht darin, dass der Anforderer die Anfrageparameter mit einem eindeutigen Schlüssel hashen kann. Als Zahlungsdienstleister können Sie dann denselben Hash auf Ihrer Seite berechnen und die Anfrage nur dann akzeptieren, wenn sie mit Ihrer Berechnung übereinstimmt.

Was passiert mit der Referer, wenn eine HTTP-Händlerwebsite ohne Verweis-URL zu einem HTTPS-Zahlungsanbieter weiterleitet?

In der Anfrage an den HTTPS-Zahlungsanbieter ist kein Referer sichtbar, 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. Beachte auch, dass Chrome durch eine neue Standardrichtlinie keine Auswirkungen auf dieses Verhalten hat.

Fazit

Mit einer solchen Richtlinie können Sie den Datenschutz für Ihre Nutzer erhöhen.

Weitere Informationen zu den verschiedenen Techniken zum Schutz Ihrer Nutzer finden Sie in der Sammlung Sicher von web.dev.

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

Ressourcen