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

Maud Nalpas

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

Zusammenfassung

• Unerwartete ursprungsübergreifende Informationslecks beeinträchtigen die Privatsphäre von Webnutzern. Eine schützende Referrer-Policy kann helfen.
• Sie sollten eine Referrer-Policy von strict-origin-when-cross-origin festlegen. So bleibt der Referrer weitestgehend nützlich und gleichzeitig wird das Risiko von Datenlecks über Ursprünge hinweg verringert.
• Verwenden Sie keine Referrer für den Schutz vor websiteübergreifender Anfragefälschung (Cross-Site Request Forgery, CSRF). Verwenden Sie CSRF-Tokens stattdessen und andere Header als zusätzliche Sicherheitsebene.

Grundlagen zu Referer und Referrer-Policy

HTTP-Anfragen können einen optionalen Referer Header, der den Ursprung oder die URL der Webseite angibt, von der die Anfrage stammt, enthalten. Der Referrer-Policy Header 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.

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

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

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

Aus Referer-Werten lassen sich viele Informationen gewinnen. Ein Analysedienst kann beispielsweise anhand dieser Werte feststellen, dass 50% der Besucher auf site-two.example von social-network.example kamen. Wenn jedoch die vollständige URL, einschließlich Pfad und Abfragestring, im Referer über Ursprünge hinweg gesendet wird, kann dies die Privatsphäre der Nutzer gefährden und Sicherheitsrisiken mit sich bringen:

Die URLs 1 bis 5 enthalten private und manchmal sensible oder identifizierbare Informationen. Wenn diese Informationen unbemerkt über Ursprünge hinweg weitergegeben werden, kann dies die Privatsphäre von Webnutzern beeinträchtigen.

URL 6 ist eine URL für Funktionen. Wenn jemand anderes als der beabsichtigte Nutzer diese URL 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 verfügbar gemacht werden, können Sie eine Referrer-Policy festlegen.

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

Sie können eine von acht Richtlinien auswählen. Je nach Richtlinie können die Daten, die über den Header Referer (und document.referrer) verfügbar sind, Folgendes sein:

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

Einige Richtlinien sind so konzipiert, dass sie je nach Kontext unterschiedlich funktionieren: ursprungsübergreifende oder ursprungsbezogene Anfrage, ob das Ziel der Anfrage genauso sicher ist wie der Ursprung oder beides. Das ist nützlich, um die Menge der Informationen zu begrenzen, die über Ursprünge hinweg oder an weniger sichere Ursprünge weitergegeben werden, während der Referrer auf Ihrer eigenen Website weiterhin umfassende Informationen liefert.

In der folgenden Tabelle wird gezeigt, wie Referrer-Policies die URL-Daten einschränken, die über den Header `Referer` und document.referrer verfügbar sind:

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

Beachten Sie beim Festlegen einer Referrer-Policy Folgendes:

• Alle Richtlinien, die das Schema (HTTPS im Vergleich zu HTTP) berücksichtigen (strict-origin, no-referrer-when-downgrade und strict-origin-when-cross-origin), behandeln Anfragen von einem HTTP-Ursprung zu einem anderen HTTP-Ursprung genauso wie Anfragen von einem HTTPS-Ursprung zu einem anderen HTTPS-Ursprung, obwohl HTTP weniger sicher ist. Bei diesen Richtlinien ist es wichtig, ob eine Sicherheitsherabstufung erfolgt, d. h., ob die Anfrage Daten von einem verschlüsselten Ursprung an einen unverschlüsselten Ursprung weitergeben kann, wie bei HTTPS-zu-HTTP-Anfragen. Eine HTTP-zu-HTTP-Anfrage ist vollständig unverschlüsselt, daher gibt es keine Herabstufung.
• Wenn eine Anfrage ursprungsbezogen ist, ist das Schema (HTTPS oder HTTP) identisch, sodass es keine Sicherheitsherabstufung gibt.

Standardmäßige Referrer-Policies in Browsern

Stand Oktober 2021

Wenn keine Referrer-Policy festgelegt ist, verwendet der Browser seine Standardrichtlinie.

Best Practices für das Festlegen einer Referrer-Policy

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

• Als HTTP-Header
• In Ihrem HTML
• Über JavaScript pro Anfrage

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

Der HTTP-Header und das Meta-Element sind beide 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. 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 no-referrer-when-downgrade-Policy angefordert. Alle anderen Anfragen für Unterressourcen von dieser Seite folgen der strict-origin-when-cross-origin-Policy.

Wie kann ich die Referrer-Policy sehen?

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

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

Welche Richtlinie sollten Sie für Ihre Website festlegen?

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

Warum „explizit“?

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

• Verschiedene Browser haben unterschiedliche Standardrichtlinien. Wenn Sie sich auf die Standardeinstellungen des Browsers verlassen, verhält sich Ihre Website in verschiedenen Browsern nicht vorhersehbar.
• Browser verwenden immer strengere Standardeinstellungen wie strict-origin-when-cross-origin und Mechanismen wie das Kürzen von Referrern für ursprungsübergreifende Anfragen. Wenn Sie sich explizit für eine datenschutzfreundliche Richtlinie entscheiden, bevor sich die Standardeinstellungen des Browsers ändern, haben Sie die Kontrolle und können Tests nach Bedarf ausfü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 unbedingt ändern), möchten Sie nicht, dass die URLs Ihrer Website in Nicht-HTTPS-Anfragen weitergegeben werden. Da jeder im Netzwerk diese Anfragen sehen kann, würden Lecks Ihre Nutzer Person-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 ursprungsübergreifenden Anfrage gibt no-referrer-when-downgrade die vollständige URL weiter, 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. Als datenschutzfreundliche Optionen bleiben also strict-origin-when-cross-origin, strict-origin und no-referrer übrig.
• Nützlich: no-referrer und strict-origin geben die vollständige URL nie weiter, auch nicht bei ursprungsbezogenen Anfragen. Wenn Sie die vollständige URL benötigen, ist strict-origin-when-cross-origin eine bessere Option.

All das bedeutet, dass strict-origin-when-cross-origin in der Regel eine sinnvolle Wahl ist.

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

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 strenger) nicht alle Ihre Anwendungsfälle abdeckt?

In diesem Fall sollten Sie schrittweise vorgehen: Legen Sie eine schützende 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 document.referrer oder den Header Referer für websiteübergreifende 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 identifizierbare oder sensible Daten enthalten, legen Sie eine schützende Richtlinie fest.

Best Practices für eingehende Anfragen

Hier finden Sie einige Richtlinien für den Fall, dass Ihre Website die Referrer-URL eingehender Anfragen verwendet.

Nutzerdaten schützen

Der Referer kann private, personenbezogene oder identifizierbare Daten enthalten. Behandeln Sie ihn daher entsprechend.

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

Die Verwendung des Referrers aus eingehenden ursprungsübergreifenden Anfragen ist mit einigen Einschränkungen verbunden:

• Wenn Sie keine Kontrolle über die Implementierung des Anfragestellers haben, können Sie keine Annahmen über den Header Referer (und document.referrer) treffen, den Sie erhalten. Der Anfragesteller kann jederzeit zu einer no-referrer-Policy oder allgemein zu einer strengeren Policy als zuvor wechseln. Das bedeutet, dass Sie weniger Daten vom Referer erhalten als zuvor.
• Browser verwenden standardmäßig immer häufiger die Referrer-Policy strict-origin-when-cross-origin. Das bedeutet, dass Sie bei eingehenden ursprungsübergreifenden Anfragen möglicherweise nur den Ursprung anstelle einer vollständigen Referrer-URL erhalten, wenn für die Absenderwebsite keine Richtlinie festgelegt ist.
• Browser können die Art und Weise ändern, wie sie Referer verwalten. Einige Browserentwickler entscheiden sich beispielsweise möglicherweise dafür, Referrer in ursprungsübergreifenden Anfragen für Unterressourcen immer auf Ursprünge zu beschränken, um die Privatsphäre der Nutzer zu schützen.
• Der Header Referer (und document.referrer) kann mehr Daten enthalten, als Sie benötigen. Er kann beispielsweise eine vollständige URL enthalten, wenn 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 die Referrer-URL eingehender ursprungsübergreifender Anfragen verwendet.
• Ihre Website erhält nicht mehr den Teil der Referrer-URL, den sie in einer ursprungsübergreifenden Anfrage benötigt. Das passiert, wenn der Anfragesteller seine Richtlinie ändert oder wenn keine Richtlinie festgelegt ist und sich die Richtlinie der Standardeinstellung des Browsers geändert hat (wie in Chrome 85).

Um Alternativen zu definieren, analysieren Sie zuerst, 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, liefern Ihnen Header wie Origin und Sec-Fetch-Site den 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, Abfrageparameter usw.)

• Anfrageparameter können Ihren Anwendungsfall abdecken, 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 als Alternative dienen. Extrahieren Sie nur den Pfadteil der URL und übergeben Sie ihn als Argument, damit potenziell sensible Informationen in den URL-Parametern nicht weitergegeben werden.

Wenn Sie diese Alternativen nicht verwenden können:

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

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

Ein Anfragesteller kann jederzeit entscheiden, den Referrer nicht zu senden, indem er eine no-referrer-Policy 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 verwenden Sie SameSite und anstelle von Referer Header wie Origin (verfügbar bei POST- und CORS-Anfragen) und Sec-Fetch-Site , falls verfügbar.

Protokollieren und Fehler beheben

Achten Sie darauf, die personenbezogenen oder sensiblen Daten der Nutzer zu schützen, die sich möglicherweise im Referer befinden.

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

Zahlungen

Zahlungsanbieter verlassen sich möglicherweise auf den Header Referer 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 zu payment-provider.example weiter, um die Transaktion zu verwalten.
• payment-provider.example vergleicht den Referer dieser Anfrage mit einer Liste zulässiger Referer-Werte, die von den Händlern eingerichtet wurden. Wenn er mit keinem Eintrag in der Liste übereinstimmt, lehnt payment-provider.example die Anfrage ab. Wenn er übereinstimmt, kann der Nutzer mit der Transaktion fortfahren.

Best Practices für Sicherheitsprüfungen im Zahlungsablauf

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

Wenn Zahlungsanbieter den Referer prüfen, können sie naive Angreifer erkennen, die keine no-referrer-Policy festgelegt haben. Wenn Sie den Referer als erste Prüfung verwenden:

• Gehen Sie nicht davon aus, dass der Referer immer vorhanden ist. Wenn er vorhanden ist, prüfen Sie ihn nur anhand der Mindestdaten, die er enthalten kann, nämlich des Ursprungs.
  • 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 keinen Referer oder einen Referer-Wert erwarten, der nur der Ursprung der anfragenden Website ist, vermeiden Sie Fehler, die durch Annahmen zur Referrer-Policy des Händlers entstehen können.
• Wenn der Referer nicht vorhanden ist oder wenn er vorhanden ist und Ihre grundlegende Referer-Ursprungsprüfung erfolgreich war, können Sie zu einer anderen, zuverlässigeren Überprüfungsmethode übergehen.

Um Zahlungen zuverlässiger zu überprüfen, lassen Sie den Anfragesteller die Anfrageparameter zusammen 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 Policy zu einem HTTPS-Zahlungsanbieter weiterleitet?

Im 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. Die Änderung von Chrome zu einer neuen Standardrichtlinie ändert dieses Verhalten nicht.

Fazit

Eine schützende Referrer-Policy ist eine gute Möglichkeit, Ihren Nutzern mehr Datenschutz zu bieten.

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 hinsichtlich Datenschutz und Sicherheit auf MDN
• Chrome-Änderung: Blink-Absicht zur Implementierung
• Chrome-Änderung: Blink-Absicht zur Veröffentlichung
• Chrome-Änderung: Statuseintrag
• Chrome-Änderung: Blogpost zur Betaversion von Chrome 85
• GitHub-Thread zum Kürzen von Referrern: Was verschiedene Browser tun
• Referrer-Policy-Spezifikation

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