Diese Seite wurde von der Cloud Translation API übersetzt.

Neue Standard-Verweisrichtlinie für Chrome – strict-origin-when-cross-origin

Maud Nalpas

Bevor wir beginnen:

Weitere Informationen zum Unterschied zwischen „Website“ und „Ursprung“ finden Sie in diesem Hilfeartikel.
Im Referer-Header fehlt aufgrund eines ursprünglichen Rechtschreibfehlers in der Spezifikation ein R. Der Referrer-Policy-Header und das referrer in JavaScript und das DOM sind richtig geschrieben.

Zusammenfassung

In Browsern werden immer mehr datenschutzfreundliche Standardrichtlinien für Verweis-URLs genutzt, um ein gutes Fallback zu bieten, wenn für eine Website keine Richtlinien festgelegt sind.
Chrome plant, strict-origin-when-cross-origin schrittweise in Version 85 als Standardrichtlinie zu aktivieren. Dies kann sich auf Anwendungsfälle auswirken, die auf dem Verweiswert aus einer anderen Quelle basieren.
Dies ist die neue Standardeinstellung. Websites können jedoch weiterhin eine Richtlinie ihrer Wahl auswählen.
Aktivieren Sie das Flag unter chrome://flags/#reduced-referrer-granularity, um die Änderung in Chrome auszuprobieren. Sie können sich auch diese Demo ansehen, um die Änderung in Aktion zu sehen.
Neben der Verweisrichtlinie kann sich auch die Art und Weise ändern, wie Browser mit Verweis-URLs umgehen. Behalten Sie diese daher im Auge.

Was ändert sich und warum?

HTTP-Anfragen können den optionalen Referer-Header enthalten, der die Ursprungs- oder Webseiten-URL angibt, über die die Anfrage gestellt wurde. Der Header Referer-Policy definiert, welche Daten im Header Referer sowie für die Navigation und iFrames im document.referrer des Ziels zur Verfügung gestellt werden.

Welche Informationen in einer Anfrage von Ihrer Website über den Referer-Header gesendet werden, wird durch den von Ihnen festgelegten Referrer-Policy-Header bestimmt.

Diagramm: Referrer-URL, die in einer Anfrage gesendet wurde. — *Richtlinie für Referrer-URL und Verweis-URL.*

Wenn keine Richtlinie konfiguriert ist, wird der Standardwert des Browsers verwendet. Websites orientieren sich häufig an den Standardeinstellungen des Browsers.

Bei Navigationen und iFrames kann auch mithilfe von document.referrer über JavaScript auf die Daten im Referer-Header zugegriffen werden.

Bis vor Kurzem war no-referrer-when-downgrade eine weitverbreitete Standardrichtlinie in allen Browsern. Viele Browser sind jedoch dabei, auf datenschutzfreundlichere Standardeinstellungen umzustellen.

Chrome plant ab Version 85, die Standardrichtlinie von „no-referrer-when-downgrade“ zu „strict-origin-when-cross-origin“ zu ändern.

Wenn keine Richtlinie für Ihre Website festgelegt ist, verwendet Chrome standardmäßig strict-origin-when-cross-origin. Sie können weiterhin eine Richtlinie Ihrer Wahl festlegen. Diese Änderung wirkt sich nur auf Websites aus, für die keine Richtlinie festgelegt wurde.

Was bedeutet diese Änderung?

strict-origin-when-cross-origin bietet mehr Datenschutz. Mit dieser Richtlinie wird nur der origin-Wert im Referer-Header von ursprungsübergreifenden Anfragen gesendet.

Dadurch werden Datenlecks verhindert, die möglicherweise über andere Teile der vollständigen URL wie Pfad und Abfragestring zugänglich sind.

Diagramm: Referrer, der abhängig von der Richtlinie für eine ursprungsübergreifende Anfrage gesendet wird. — *Der Verweis-URL (und „document.referrer“) wurde für eine ursprungsübergreifende Anfrage gesendet, abhängig von der Richtlinie.*

Beispiel:

Ursprungsübergreifende Anfrage, die von https://site-one.example/stuff/detail?tag=red an https://site-two.example/... gesendet wird:

Mit no-referrer-when-downgrade: Verweis-URL: https://site-one.example/stuff/detail?tag=red.
Mit strict-origin-when-cross-origin: Referrer-URL: https://site-one.example/.

Was bleibt gleich?

Wie no-referrer-when-downgrade ist auch strict-origin-when-cross-origin sicher: Es ist keine Verweis-URL (Referer-Header und document.referrer) vorhanden, wenn die Anfrage von einem (sicheren) HTTPS-Ursprung zu einem HTTP-Ursprung (nicht sicher) gestellt wird. Wenn Ihre Website HTTPS verwendet (falls nicht, legen Sie es zur Priorität fest), werden die URLs Ihrer Website keine Datenlecks für Nicht-HTTPS-Anfragen verursachen, da jeder im Netzwerk diese sehen kann und Ihre Nutzer so einem Man-in-the-Middle-Angriff ausgesetzt werden.
Innerhalb desselben Ursprungs ist der Headerwert Referer die vollständige URL.

Beispiel: Anfrage am selben Ursprung, gesendet von https://site-one.example/stuff/detail?tag=red an https://site-one.example/...:

Mit strict-origin-when-cross-origin: Verweis-URL: https://site-one.example/stuff/detail?tag=red

Welche Auswirkungen hat das?

Laut Diskussionen mit anderen Browsern und eigenen Tests von Chrome in Chrome 84 ist davon auszugehen, dass die für den Nutzer sichtbare Funktion nur begrenzt funktioniert.

Serverseitiges Logging oder Analysen, für die die vollständige Referrer-URL verfügbar ist, werden wahrscheinlich durch den reduzierten Detaillierungsgrad dieser Informationen beeinträchtigt.

Was muss ich tun?

Für Chrome ist geplant, die neue Standardrichtlinie für Verweis-URLs in Version 85 einzuführen (Juli 2020 für die Betaversion, August 2020 für die stabile Version). Der Status wird im Chrome-Statuseintrag angezeigt.

Veränderung verstehen und erkennen

Um zu verstehen, was sich durch die neuen Standardeinstellungen in der Praxis ändert, können Sie sich diese Demo ansehen.

Mit dieser Demo können Sie auch herausfinden, welche Richtlinie in der von Ihnen ausgeführten Chrome-Instanz angewendet wird.

Testen Sie die Änderung und finden Sie heraus, ob sie sich auf Ihre Website auswirkt.

Ab Chrome 81 können Sie die Änderung bereits testen: Rufen Sie in Chrome chrome://flags/#reduced-referrer-granularity auf und aktivieren Sie das Flag. Wenn dieses Flag aktiviert ist, verwenden alle Websites ohne Richtlinie den neuen Standardwert strict-origin-when-cross-origin.

Chrome-Screenshot: Aktivieren des Flags chrome://flags/#reduced-referrer-granularity. — *Flag aktivieren.*

Sie können jetzt das Verhalten Ihrer Website und Ihres Backends prüfen.

Außerdem solltest du prüfen, ob die Codebasis deiner Website die Referrer-URL verwendet – entweder über den Referer-Header eingehender Anfragen auf dem Server oder über document.referrer in JavaScript.

Bestimmte Funktionen auf deiner Website funktionieren eventuell nicht mehr richtig oder verhalten sich anders, wenn du die Referrer-URL von Anfragen von einem anderen Ursprung an deine Website verwendest (genauer gesagt den Pfad und/oder Abfragestring) UND dieser Ursprung die standardmäßige Verweisrichtlinie des Browsers verwendet, d.h. wenn keine Richtlinie festgelegt ist.

Falls sich dies auf Ihre Website auswirkt, sollten Sie Alternativen erwägen.

Wenn Sie die Verweis-URL verwenden, um auf den vollständigen Pfad oder den Abfragestring für Anfragen an Ihre Website zuzugreifen, haben Sie mehrere Möglichkeiten:

Verwenden Sie alternative Techniken und Header wie Origin und Sec-fetch-Site für den Schutz, das Logging und andere Anwendungsfälle von CSRF. Weitere Informationen finden Sie im Hilfeartikel Richtlinien für Verweis-URLs und Verweis-URLs: Best Practices.
Sie können sich mit den Partnern auf eine bestimmte Richtlinie einigen, wenn dies erforderlich und für Ihre Nutzer transparent ist. Die Zugriffssteuerung – wenn die Referrer-URL von Websites verwendet wird, um anderen Quellen bestimmten Zugriff auf ihre Ressourcen zu gewähren – könnte ein solcher Fall sein. Mit der Änderung von Chrome wird der Ursprung allerdings weiterhin im Referer-Header (und in document.referrer) weitergegeben.

Bei den meisten Browsern geht es in Bezug auf die Verweis-URL in eine ähnliche Richtung. Weitere Informationen finden Sie in den Browser-Standardeinstellungen und ihrer Weiterentwicklung unter Referrer-URL und Verweisrichtlinie: Best Practices.

Implementieren Sie eine explizite, datenschutzfreundliche Richtlinie auf Ihrer gesamten Website.

Welche Referer sollte in Anfragen gesendet werden, die von deiner Website stammen? Welche Richtlinie solltest du für deine Website festlegen?

Auch wenn du die Änderung in Chrome erwähnst, ist es ratsam, eine explizite, datenschutzfreundliche Richtlinie wie strict-origin-when-cross-origin oder strengere Richtlinien festzulegen.

So sind Ihre Nutzer besser geschützt und Ihre Website lässt sich in verschiedenen Browsern besser vorhersehen. Meistens lässt sich damit die Kontrolle behalten, anstatt dass Ihre Website von den Standardeinstellungen des Browsers abhängig ist.

Weitere Informationen zum Festlegen einer Richtlinie finden Sie unter Referrer-URL und Referrer-Policy: Best Practices.

Chrome Enterprise

Die Chrome-Unternehmensrichtlinie ForceLegacyDefaultReferrerPolicy ist für IT-Administratoren verfügbar, die die vorherige Standardrichtlinie für Verweis-URLs von no-referrer-when-downgrade in Unternehmensumgebungen erzwingen möchten. Dadurch haben Unternehmen mehr Zeit, um ihre Anwendungen zu testen und zu aktualisieren.

Diese Richtlinie wird in Chrome 88 entfernt.

Feedback geben

Möchtest du uns Feedback geben oder etwas melden? Senden Sie uns Feedback zum geplanten Versand von Chrome oder twittern Sie Ihre Fragen unter @maudnals.

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