Diese Seite wurde von der Cloud Translation API übersetzt.

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

Maud Nalpas

Twitter GitHub

Bevor wir beginnen:

Wenn Sie den Unterschied zwischen „Website“ und „Ursprung“ nicht kennen, lesen Sie den Artikel Informationen zu „same-site“ und „same-origin“.
Im Referer-Header fehlt ein R, da die Spezifikation ursprünglich falsch geschrieben wurde. Der Referrer-Policy-Header und referrer in JavaScript und das DOM sind richtig geschrieben.

Zusammenfassung

Browser entwickeln immer häufiger datenschutzfreundliche Standard-Referrer-URL-Richtlinien, die ein gutes Fallback darstellen, wenn für eine Website keine Richtlinie festgelegt ist.
Für Chrome ist geplant, strict-origin-when-cross-origin nach und nach als Standardrichtlinie in Version 85 zu aktivieren. Dies kann sich auf Anwendungsfälle auswirken, in denen der Referrer-Wert von einem anderen Ursprung verwendet wird.
Das 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. Sie können sich auch diese Demo ansehen, um die Änderung in Aktion zu sehen.
Neben der Richtlinie für Verweis-URLs kann sich auch die Art und Weise ändern, wie Browser mit Referrern umgehen. Behalten Sie diese im Auge.

Was ändert sich und warum?

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

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

Diagramm: In einer Anfrage gesendeter Referrer. — *Referrer-URL-Richtlinie und Referrer-URL.*

Wenn keine Richtlinie konfiguriert ist, wird der Standardbrowser des Browsers verwendet. Websites richten sich oft nach der Standardeinstellung des Browsers.

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

Bis vor Kurzem war no-referrer-when-downgrade eine weitverbreitete Standardrichtlinie in allen Browsern. Mittlerweile befinden sich viele Browser jedoch in einer Phase der Umstellung auf zusätzliche datenschutzfreundlichere Standardeinstellungen.

Die Chrome-Standardrichtlinie wird ab Version 85 von no-referrer-when-downgrade auf strict-origin-when-cross-origin umgestellt.

Wenn für Ihre Website keine Richtlinie festgelegt ist, verwendet Chrome also 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 Richtlinien festgelegt wurden.

Was bedeutet diese Änderung?

strict-origin-when-cross-origin bietet einen höheren Datenschutz. Mit dieser Richtlinie wird nur der origin im Referer-Header von ursprungsübergreifenden Anfragen gesendet.

Dadurch werden Datenlecks verhindert, die über andere Teile der vollständigen URL zugänglich sind, z. B. über Pfad und Abfragestring.

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

Beispiel:

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

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

Was bleibt gleich?

Wie no-referrer-when-downgrade ist auch strict-origin-when-cross-origin sicher: Es ist keine Referrer-URL (Referer-Header und document.referrer) vorhanden, wenn die Anfrage von einem HTTPS-Ursprung (sicher) an eine HTTP-Quelle (unsicher) gesendet wird. Wenn Ihre Website HTTPS verwendet (falls nicht, sollte dies eine Priorität sein), werden die URLs Ihrer Website bei Nicht-HTTPS-Anfragen nicht nach außen gelangen, da jeder im Netzwerk diese Daten sehen kann. Dies würde Ihre Nutzer also Man-in-the-Middle-Angriffen aussetzen.
Innerhalb desselben Ursprungs ist der Referer-Headerwert die vollständige URL.

Beispiel: Anfrage für denselben 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 Gesprächen mit anderen Browsern und den von Chrome durchgeführten Tests in Chrome 84 ist für den Nutzer sichtbare Fehler voraussichtlich nur begrenzt sichtbar.

Serverseitiges Logging oder Analysen, bei denen die vollständige Verfügbarkeit der Referrer-URL erforderlich ist, werden wahrscheinlich durch den reduzierten Detaillierungsgrad dieser Informationen beeinträchtigt.

Was muss ich tun?

Die neue Standardrichtlinie für Verweis-URLs wird voraussichtlich in Chrome 85 eingeführt (Juli 2020 in der Betaphase und August 2020 in der stabilen Version). Den Status finden Sie im Chrome-Statuseintrag.

Änderungen verstehen und erkennen

Informationen dazu, was sich die neuen Standardeinstellungen in der Praxis ändern, finden Sie in dieser Demo.

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

Testen Sie die Änderung und finden Sie heraus, ob sich das 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, verwenden alle Websites ohne Richtlinie den neuen Standardwert strict-origin-when-cross-origin.

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, Auswirkungen zu erkennen, besteht darin, zu prüfen, ob die Codebasis Ihrer Website die Referrer-URL verwendet – entweder über den Referer-Header eingehender Anfragen auf dem Server oder über document.referrer in JavaScript.

Wenn Sie die Verweis-URL von Anfragen eines anderen Ursprungs zu Ihrer Website verwenden (genauer gesagt den Pfad und/oder den Abfragestring), funktionieren bestimmte Funktionen auf Ihrer Website möglicherweise nicht mehr oder funktionieren anders, UND für diesen Ursprung wird die standardmäßige Verweisrichtlinie des Browsers verwendet, d.h. es wurde keine Richtlinie festgelegt.

Wenn dies Ihre Website betrifft, sollten Sie Alternativen in Betracht ziehen.

Wenn Sie die Referrer-URL verwenden, um auf den vollständigen Pfad oder 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 CSRF-Schutz, das Logging und andere Anwendungsfälle. Weitere Informationen finden Sie im Hilfeartikel Empfehlungs- und Verweisrichtlinie: Best Practices.
Sie können sich mit 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 bestimmten Zugriff auf ihre Ressourcen für andere Ursprünge zu gewähren – kann ein solcher Fall sein. Mit der Änderung in Chrome wird der Ursprung jedoch weiterhin im Referer-Header (und in document.referrer) geteilt.

Beachten Sie, dass sich die meisten Browser in Bezug auf die Verweis-URL in eine ähnliche Richtung bewegen (siehe Standardeinstellungen des Browsers und deren Entwicklung unter Referrer-URL und Referrer-URL-Richtlinie: Best Practices).

Explizite, datenschutzfreundlichere Richtlinie auf Ihrer gesamten Website implementieren

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

Auch wenn die Änderungen bei Chrome in Betracht gezogen werden, ist es ratsam, explizite, datenschutzfreundliche Richtlinien wie strict-origin-when-cross-origin festzulegen oder schon jetzt eine striktere Richtlinie festzulegen.

Das trägt zum Schutz Ihrer Nutzer bei und sorgt dafür, dass das Verhalten Ihrer Website in verschiedenen Browsern besser vorhersehbar ist. In den meisten Fällen gibt es die Kontrolle – die Website muss nicht von den Standardeinstellungen des Browsers abhängig sein.

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

Über Chrome Enterprise

Die Chrome-Unternehmensrichtlinie ForceLegacyDefaultReferrerPolicy steht IT-Administratoren zur Verfügung, die die vorherige Standard-Verweisrichtlinie no-referrer-when-downgrade in Unternehmensumgebungen erzwingen möchten. Dadurch haben Unternehmen mehr Zeit, ihre Anwendungen zu testen und zu aktualisieren.

Diese Richtlinie wird in Chrome 88 entfernt.

Feedback geben

Möchten Sie uns Feedback geben oder etwas melden? Teilen Sie uns Ihr Feedback zur Auslieferungsabsicht von Chrome mit oder twittern Sie Ihre Fragen an @maudnals.

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