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

Maud Nalpas

Bevor wir beginnen:

Wenn Sie sich nicht sicher sind, was der Unterschied zwischen „Website“ und „Ursprung“ ist, lesen Sie den Hilfeartikel „Same-Site“ und „Same-Origin“.
Im Header Referer fehlt ein „r“, da in der Spezifikation ursprünglich ein Tippfehler enthalten war. Der Header Referrer-Policy und referrer in JavaScript und im DOM sind korrekt geschrieben.

Zusammenfassung

Browser entwickeln sich in Richtung datenschutzfreundlicher Standard-Verweisrichtlinien, um einen guten Fallback zu bieten, wenn für eine Website keine Richtlinie festgelegt ist.
Chrome plant, strict-origin-when-cross-origin in Version 85 schrittweise als Standardrichtlinie zu aktivieren. Dies kann sich auf Anwendungsfälle auswirken, die auf dem Verweiswert eines anderen Ursprungs basieren.
Dies ist die neue Standardeinstellung, aber Websites können weiterhin eine Richtlinie ihrer Wahl auswählen.
Wenn Sie die Änderung in Chrome ausprobieren möchten, aktivieren Sie das Flag unter chrome://flags/#reduced-referrer-granularity. In dieser Demo können Sie sich die Änderung in Aktion ansehen.
Neben der Verweisrichtlinie kann sich auch die Art und Weise ändern, wie Browser mit Verweisen umgehen. Behalten Sie das im Auge.

Was ändert sich und warum?

HTTP-Anfragen können den optionalen Referer Header enthalten, der die URL des Ursprungs oder der Webseite angibt, von der die Anfrage stammt. Der Referer-Policy Header definiert, welche Daten im Referer Header und für die Navigation und iFrames in document.referrer des Ziels verfügbar gemacht werden.

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

Diagramm: In einer Anfrage gesendeter Referrer. — *Referrer-Policy und Referer.*

Wenn keine Richtlinie festgelegt ist, wird die Standardeinstellung des Browsers verwendet. Websites verwenden häufig die Standardeinstellung des Browsers.

Bei Navigationen und iFrames können die Daten im Header Referer auch über JavaScript mit document.referrer aufgerufen werden.

Bis vor Kurzem war no-referrer-when-downgrade eine weit verbreitete Standardrichtlinie in Browsern. Viele Browser befinden sich jedoch in einer Phase der Umstellung auf datenschutzfreundlichere Standardeinstellungen.

Chrome plant, die Standardrichtlinie ab Version 85 von no-referrer-when-downgrade auf strict-origin-when-cross-origin umzustellen.

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

Was bedeutet diese Änderung?

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

So werden keine privaten Daten weitergegeben, die über andere Teile der vollständigen URL wie den Pfad und die Abfragestring zugänglich sein können.

Diagramm: Referer, der je nach Richtlinie für eine ursprungsübergreifende Anfrage gesendet wird. — *Je nach Richtlinie gesendeter Referer (und document.referrer) für eine ursprungsübergreifende Anfrage*

Beispiel:

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

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

Was bleibt gleich?

Wie no-referrer-when-downgrade ist auch strict-origin-when-cross-origin sicher: Es ist kein Referer (Header Referer und document.referrer) vorhanden, wenn die Anfrage von einem HTTPS Ursprung (sicher) an einen HTTP-Ursprung (unsicher) gesendet wird. Wenn Ihre Website HTTPS verwendet (falls nicht, sollten Sie das unbedingt ändern), werden die URLs Ihrer Website nicht in Nicht-HTTPS Anfragen weitergegeben. Jeder im Netzwerk kann diese URLs sehen, sodass Ihre Nutzer Man-in-the-Middle-Angriffen ausgesetzt wären.
Innerhalb desselben Ursprungs ist der Wert des Headers Referer die vollständige URL.

Beispiel: Anfrage desselben Ursprungs, gesendet von https://site-one.example/stuff/detail?tag=red an https://site-one.example/…:

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

Auswirkungen

Basierend auf Gesprächen mit anderen Browsern und eigenen Tests in Chrome 84 sind nur begrenzte Probleme für Nutzer zu erwarten.

Serverseitige Protokollierung oder Analysen, bei denen die vollständige Verweis-URL verfügbar sein muss, sind wahrscheinlich von der geringeren Granularität dieser Informationen betroffen.

Was muss ich tun?

Chrome plant, die neue Standard-Verweisrichtlinie in Version 85 einzuführen (Juli 2020 für die Betaversion, August 2020 für die stabile Version). Den Status finden Sie im Chrome-Statusbericht.

Änderung verstehen und erkennen

In dieser Demo können Sie sehen, wie sich die neue Standardeinstellung in der Praxis auswirkt.

Mit dieser Demo können Sie auch erkennen, welche Richtlinie in der von Ihnen verwendeten Chrome-Instanz angewendet wird.

Änderung testen und herausfinden, ob sie sich auf Ihre Website auswirkt

Sie können die Änderung bereits ab Chrome 81 ausprobieren: Rufen Sie in Chrome chrome://flags/#reduced-referrer-granularity auf und aktivieren Sie das Flag. Wenn dieses Flag aktiviert ist, wird für alle Websites ohne Richtlinie die neue Standardeinstellung strict-origin-when-cross-origin verwendet.

Chrome-Screenshot: So aktivieren Sie das Flag chrome://flags/#reduced-referrer-granularity. — *Flag aktivieren*

Sie können jetzt prüfen, wie sich Ihre Website und Ihr Back-End verhalten.

Eine weitere Möglichkeit, die Auswirkungen zu erkennen, besteht darin, zu prüfen, ob im Code Ihrer Website der Referer verwendet wird. Das kann entweder über den Header Referer eingehender Anfragen auf dem Server oder über document.referrer in JavaScript erfolgen.

Bestimmte Funktionen auf Ihrer Website funktionieren möglicherweise nicht mehr oder verhalten sich anders, wenn Sie den Referer von Anfragen von einem anderen Ursprung an Ihre Website verwenden (insbesondere den Pfad und/oder die Abfragestring) UND für diesen Ursprung die Standard-Verweisrichtlinie des Browsers verwendet wird (d.h. keine Richtlinie festgelegt ist).

Wenn sich die Änderung auf Ihre Website auswirkt, sollten Sie Alternativen in Betracht ziehen

Wenn Sie den Referer verwenden, um auf den vollständigen Pfad oder die 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 Ihren CSRF-Schutz, die Protokollierung und andere Anwendungsfälle. Weitere Informationen finden Sie unter Referer und Referrer-Policy: Best Practices.
Sie können sich mit Partnern auf eine bestimmte Richtlinie einigen, wenn dies erforderlich und für Ihre Nutzer transparent ist. Ein solcher Fall kann die Zugriffssteuerung sein, wenn der Referer von Websites verwendet wird, um anderen Ursprüngen bestimmten Zugriff auf ihre Ressourcen zu gewähren. Mit der Änderung von Chrome wird der Ursprung jedoch weiterhin im Header Referer (und in document.referrer) weitergegeben.

Die meisten Browser bewegen sich in Bezug auf den Referer in eine ähnliche Richtung. Weitere Informationen finden Sie unter Browser Standardeinstellungen und ihre Entwicklung im Hilfeartikel Referer und Referrer-Policy: Best Practices.

Explizite, datenschutzfreundliche Richtlinie auf Ihrer gesamten Website implementieren

Welcher Referer sollte in Anfragen gesendet werden, die von Ihrer Website stammen ? Welche Richtlinie sollten Sie also für Ihre Website festlegen?

Auch wenn Sie die Änderung von Chrome berücksichtigen, ist es eine gute Idee, jetzt eine explizite, datenschutzfreundliche Richtlinie wie strict-origin-when-cross-origin oder eine strengere Richtlinie festzulegen.

So schützen Sie Ihre Nutzer und das Verhalten Ihrer Website ist in allen Browsern besser vorhersagbar. Vor allem haben Sie die Kontrolle und Ihre Website ist nicht von den Standardeinstellungen des Browsers abhängig.

Weitere Informationen zum Festlegen einer Richtlinie finden Sie unter Referer und Referrer-Policy: Best Practices für Details.

Chrome Enterprise

Die Chrome Enterprise-Richtlinie ForceLegacyDefaultReferrerPolicy ist für IT-Administratoren verfügbar, die die vorherige Standard-Verweisrichtlinie no-referrer-when-downgrade in Unternehmensumgebungen erzwingen möchten. So haben Unternehmen mehr Zeit, ihre Anwendungen zu testen und zu aktualisieren.

Diese Richtlinie wird in Chrome 88 entfernt.

Feedback geben

Haben Sie Feedback oder möchten Sie etwas melden? Geben Sie Feedback zu den Plänen von Chrome oder twittern Sie Ihre Fragen an @maudnals.

Vielen Dank an alle Reviewer 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.