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

Maud Nalpas

Auf dieser Seite werden einige Best Practices zum Festlegen der Referrer-Policy und zur Verwendung des Referrers in eingehenden Anfragen beschrieben.

Zusammenfassung

• Unerwartete ursprungsübergreifende Datenlecks beeinträchtigen die Privatsphäre von Web-Nutzern. Eine schützende Referrer-Richtlinie kann helfen.
• Du kannst die Referrer-Richtlinie auf strict-origin-when-cross-origin setzen. Dadurch bleibt der Großteil der Nützlichkeit des Referrers erhalten, während das Risiko von Datenlecks ursprungsübergreifend minimiert wird.
• Verwenden Sie keine Referrer zum Schutz vor websiteübergreifenden Anfragen (CSRF). Verwenden Sie stattdessen CSRF-Tokens und andere Header als zusätzliche Sicherheitsebene.

Hinweis:

• Wenn Sie sich nicht sicher sind, was der Unterschied zwischen „Website“ und „Ursprung“ ist, lesen Sie den Artikel Understanding „same-site“ and „same-origin“.
• Im Header Referer fehlt ein „r“ aufgrund eines Rechtschreibfehlers in der ursprünglichen Spezifikation. Der Header Referrer-Policy und referrer in JavaScript und im DOM sind richtig geschrieben.

Referer und Referrer-Policy – Grundlagen

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

Eine HTTP-Anfrage mit einem Referer-Header.

Der Referer-Header 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 für eine Seite erforderlich sind.

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

Aus Referer-Werten können Sie viel lernen. Ein Analysedienst könnte sie beispielsweise verwenden, um festzustellen, dass 50 % der Besucher von site-two.example von social-network.example kamen. Wenn jedoch die vollständige URL, einschließlich Pfad und Abfragestring, ursprungsübergreifend im Referer gesendet wird, kann dies den Datenschutz gefährden und Sicherheitsrisiken verursachen:

Die Verwendung der vollständigen URL kann sich auf den Datenschutz und die Sicherheit der Nutzer auswirken.

Die URLs 1 bis 5 enthalten private Informationen und manchmal vertrauliche oder personenidentifizierbare Informationen. Wenn diese Daten unbemerkt über verschiedene Ursprünge hinweg weitergegeben werden, kann dies die Privatsphäre von Web-Nutzern gefährden.

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

Wenn du einschränken möchtest, welche Referrer-Daten für Anfragen von deiner Website zur Verfügung gestellt werden, kannst du eine Referrer-Richtlinie 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 im Referer-Header (und document.referrer) verfügbaren Daten Folgendes sein:

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

Beispiele für Referer-Daten

Einige Richtlinien sind so konzipiert, dass sie sich je nach Kontext unterschiedlich verhalten: ursprungsübergreifende oder ursprungsgleiche Anfrage, ob das Ziel der Anfrage so sicher ist wie der Ursprung oder beides. Dies ist nützlich, um die Menge der Informationen zu begrenzen, die zwischen verschiedenen Ursprüngen oder an weniger sichere Ursprünge weitergegeben werden, während die Vielfalt des Referrers innerhalb Ihrer eigenen Website erhalten bleibt.

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:

Richtlinienbereich	Richtlinienname	Referer: Keine Daten	Referer: Origin only	Referrer: Vollständige URL
Berücksichtigt den Kontext der Anfrage nicht	no-referrer	check
	origin		check
	unsafe-url			check
Fokus auf Sicherheit	strict-origin	Anfrage von HTTPS zu HTTP	Anfrage von HTTPS zu HTTPS oder von HTTP zu HTTP
	no-referrer-when-downgrade	Anfrage von HTTPS zu HTTP		Anfrage von HTTPS zu HTTPS oder von HTTP zu HTTP
Datenschutzorientiert	origin-when-cross-origin		Ursprungsübergreifende Anfrage	Anfrage am selben Ursprung
	same-origin	Ursprungsübergreifende Anfrage		Anfrage am selben Ursprung
Fokus auf Datenschutz und Sicherheit	strict-origin-when-cross-origin	Anfrage von HTTPS zu HTTP	Ursprungsübergreifende Anfrage von HTTPS zu HTTPS oder HTTP zu HTTP	Same-Origin-Anfrage

MDN bietet eine vollständige Liste der Richtlinien und Verhaltensbeispiele.

Hier sind einige Dinge, die Sie beim Festlegen einer Referrer-Richtlinie beachten sollten:

• 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 nämlich entscheidend, ob ein Downgrade der Sicherheit stattfindet, d. h. ob die Anfrage Daten von einem verschlüsselten Ursprung für einen unverschlüsselten Ursprung verfügbar machen kann, wie es bei HTTPS-zu-HTTP-Anfragen der Fall ist. Eine HTTP-zu-HTTP-Anfrage ist vollständig unverschlüsselt, sodass kein Downgrade stattfindet.
• Wenn eine Anfrage same-origin ist, bedeutet das, dass das Schema (HTTPS oder HTTP) dasselbe ist. Es gibt also keine Herabstufung der Sicherheit.

Standard-Verweisrichtlinien in Browsern

Stand: Oktober 2021

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

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 werden für Nutzer mit strengem Schutz vor Tracking und privatem Surfen die weniger restriktiven Referrer-Richtlinien no-referrer-when-downgrade, origin-when-cross-origin und unsafe-url für websiteübergreifende Anfragen ignoriert. Das bedeutet, dass der Referrer für websiteübergreifende Anfragen immer gekürzt wird, unabhängig von der Richtlinie der Website.
Edge	Der Standardwert ist strict-origin-when-cross-origin.
Safari	Die Standardeinstellung ähnelt strict-origin-when-cross-origin, mit einigen spezifischen Unterschieden. Weitere Informationen finden Sie unter Tracking-Prävention verhindern.

Best Practices zum Festlegen der Referrer-Richtlinie

Ziel: Legen Sie explizit eine datenschutzfreundliche Richtlinie fest, z. B. strict-origin-when-cross-origin(oder strenger).

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

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

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

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

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 Unterressourcenanfragen von dieser Seite folgen der strict-origin-when-cross-origin-Richtlinie.

Wie kann ich die Referrer-Richtlinie aufrufen?

securityheaders.com ist nützlich, um zu ermitteln, welche Richtlinie eine bestimmte Website oder Seite verwendet.

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

Der Bereich Netzwerk in den Chrome-Entwicklertools mit einer ausgewählten Anfrage.

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-Richtlinie festlegen, wird die Standardrichtlinie des Browsers verwendet. Tatsächlich wird auf Websites oft die Standardrichtlinie des Browsers verwendet. Das ist jedoch aus folgenden Gründen nicht ideal:

• Verschiedene Browser haben unterschiedliche Standardrichtlinien. Wenn du dich also auf die Browserstandards verlässt, verhält sich deine Website nicht in allen Browsern gleich.
• Browser übernehmen 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 die Browserstandards geändert werden, haben Sie die Kontrolle und können Tests nach Belieben 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 deine Website HTTPS verwendet (falls nicht, solltest du das unbedingt ändern), möchtest du nicht, dass die URLs deiner Website in Nicht-HTTPS-Anfragen preisgegeben werden. Da jeder im Netzwerk diese sehen kann, würden Datenlecks 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 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. Damit bleiben Ihnen strict-origin-when-cross-origin, strict-origin und no-referrer als datenschutzfreundliche Optionen.
• Nützlich: no-referrer und strict-origin geben die vollständige URL nie 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.

All dies bedeutet, dass strict-origin-when-cross-origin im Allgemeinen eine sinnvolle Wahl ist.

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

In diesem Fall solltest du progressiv vorgehen: Lege eine schützende Richtlinie wie strict-origin-when-cross-origin für deine Website fest und bei Bedarf eine weniger strenge 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 begrenzt möglicherweise document.referrer oder den Referer-Header für websiteübergreifende Anfragen. Weitere Informationen

Beispiel: Richtlinie auf Anfrageebene

script.js:

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

Was sollten Sie noch beachten?

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

Warnung: Daten, die für Sie nicht sensibel aussehen, können für Ihre Nutzer sensibel sein oder einfach nicht die Daten sein, die sie wollen oder erwarten, dass sie unbemerkt ursprungsübergreifend weitergegeben werden.

Best Practices für eingehende Anfragen

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

Nutzerdaten schützen

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

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

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

• Wenn Sie keine Kontrolle über die Implementierung des Anfrage-Emitters haben, können Sie keine Annahmen über den empfangenen Referer-Header (und document.referrer) treffen. Der Anfrageaussteller kann jederzeit zu einer no-referrer-Richtlinie oder allgemein zu einer strengeren Richtlinie als zuvor wechseln. Das bedeutet, dass du weniger Daten von der Referer erhältst 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 ändern möglicherweise die Art und Weise, wie sie Referer verwalten. Einige Browserentwickler könnten sich beispielsweise dafür entscheiden, Referrer in ursprungsübergreifenden Unterressourcenanfragen immer auf Ursprünge zu kürzen, um den Datenschutz der Nutzer zu schützen.
• Der Header Referer (und document.referrer) enthält möglicherweise mehr Daten, als Sie benötigen. Beispielsweise kann sie eine vollständige URL enthalten, wenn Sie nur wissen möchten, ob die Anfrage ursprungsübergreifend ist.

Alternativen zu Referer

In folgenden Fällen sollten Sie Alternativen in Betracht ziehen:

• Eine wichtige Funktion Ihrer Website verwendet die Referrer-URL eingehender ursprungsübergreifender Anfragen.
• Ihre Website erhält nicht mehr den Teil der Referrer-URL, der für eine ursprungsübergreifende Anfrage erforderlich ist. Dies geschieht, wenn der Anfrageaussteller seine Richtlinie ändert oder wenn er keine Richtlinie festgelegt hat und sich die Standardrichtlinie des Browsers geändert hat (wie in Chrome 85).

Wenn Sie Alternativen definieren möchten, müssen Sie zuerst analysieren, welchen Teil des Referrers Sie verwenden.

Wenn Sie nur den Ursprung benötigen,

• Wenn du den Referrer in einem Script verwendest, 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 den Origin oder geben an, ob die Anfrage ursprungsübergreifend ist. Das ist möglicherweise genau das, was Sie brauchen.

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

• Anfrageparameter können für Ihren Anwendungsfall geeignet sein, sodass Sie den Referrer nicht parsen müssen.
• Wenn du den Referrer in einem Script verwendest, das Zugriff auf die oberste Ebene der Seite hat, kann window.location.pathname als Alternative funktionieren. 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 diese Alternativen nicht verwenden können:

• Prüfen Sie, ob Sie Ihre Systeme so ändern können, dass der Anfrage-Emitter (z. B. site-one.example) die erforderlichen Informationen explizit in einer Art Konfiguration festlegt.
  • Vorteil: expliziter, datenschutzfreundlicher für site-one.example-Nutzer, zukunftssicherer.
  • Nachteil: potenziell mehr Arbeit für Sie oder die Nutzer Ihres Systems.
• Prüfen Sie, ob die Website, von der die Anfragen ausgehen, einer Referrer-Richtlinie vom Typ no-referrer-when-downgrade pro Element oder pro Anfrage zustimmen könnte.
  • Nachteil: potenziell weniger datenschutzfreundlich für site-one.example-Nutzer, möglicherweise nicht in allen Browsern unterstützt.

Schutz vor websiteübergreifender Anfragefälschung (CSRF)

Ein Anfrage-Emitter kann sich immer dafür 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. Verwenden Sie für zusätzlichen Schutz SameSite und anstelle von Referer Header wie Origin (verfügbar bei POST- und CORS-Anfragen) und Sec-Fetch-Site, falls verfügbar.

Logging und Fehlerbehebung

Achten Sie darauf, personenbezogene oder sensible Daten von Nutzern zu schützen, die sich möglicherweise in der Referer befinden.

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

Zahlungen

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

Beispiel:

• Der Nutzer klickt auf online-shop.example/cart/checkout auf den Button 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, wird die Anfrage von payment-provider.example abgelehnt. Wenn sie übereinstimmen, kann der Nutzer mit der Transaktion fortfahren.

Best Practices für Sicherheitsprüfungen im Zahlungsablauf

Als Zahlungsdienstleister kannst du die Referer als grundlegende Prüfung gegen einige 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 Zahlungsdienstleister unzugänglich macht.

Anhand des Referer können Zahlungsdienstleister möglicherweise naive Angreifer erkennen, die keine no-referrer-Richtlinie festgelegt haben. Wenn Sie die Referer als erste Prüfung verwenden:

• Gehen Sie nicht davon aus, dass die Referer immer vorhanden ist. Wenn er vorhanden ist, prüfen Sie ihn nur anhand der Mindestdaten, die er enthalten kann, also des Ursprungs.
  • Achten Sie beim Festlegen der Liste der zulässigen Referer-Werte darauf, nur den Ursprung und keinen Pfad anzugeben.
  • Beispiel: Die zulässigen Referer-Werte für online-shop.example sollten online-shop.example und nicht online-shop.example/cart/checkout sein. Wenn Sie entweder gar keinen Referer oder einen Referer-Wert erwarten, der nur der Ursprung der anfragenden Website ist, vermeiden Sie Fehler, die durch Annahmen über die Referrer-Policy des Händlers entstehen könnten.
• Wenn der Referer fehlt oder wenn er vorhanden ist und die grundlegende Referer-Ursprungsprüfung erfolgreich ist, kannst du eine andere, zuverlässigere Bestätigungsmethode verwenden.

Wenn du Zahlungen zuverlässiger verifizieren möchtest, kannst du den Anfragenden die Anfrageparameter zusammen mit einem eindeutigen Schlüssel hashen lassen. Zahlungsdienstleister 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-Zahlungsdienstleister weiterleitet?

In der Anfrage an den HTTPS-Zahlungsdienstleister 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 der Standardrichtlinie in Chrome hat keine Auswirkungen auf dieses Verhalten.

Hinweis: Wenn Ihre Website HTTP verwendet, migrieren Sie zu HTTPS.

Fazit

Eine schützende Referrer-Richtlinie ist eine gute Möglichkeit, die Privatsphäre Ihrer Nutzer besser 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: Datenschutz- und Sicherheitsbedenken auf MDN
• Chrome-Änderung: Blink-Implementierungsabsicht
• Chrome-Änderung: Blink-Intent-to-Ship
• Chrome-Änderung: Statuseintrag
• Chrome-Änderung: Blogpost zu 85 Beta
• GitHub-Thread zum Kürzen von Referrer-URLs: Was verschiedene Browser tun
• Spezifikation der Referrer-Policy

Vielen Dank an alle Prüfer 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.