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:

Wenn Sie sich nicht sicher sind, was der Unterschied zwischen „Website“ und „Ursprung“ ist, lesen Sie den Artikel „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 richtig geschrieben.

Zusammenfassung

Browser entwickeln sich in Richtung datenschutzfreundlicher Standardverweisrichtlinien, um einen guten Fallback zu bieten, wenn für eine Website keine Richtlinie festgelegt ist.
In Chrome soll strict-origin-when-cross-origin nach und nach als Standardrichtlinie in Version 85 eingeführt werden. Dies kann sich auf Anwendungsfälle auswirken, die auf den Verweiswert eines anderen Ursprungs angewiesen sind.
Dies ist die neue Standardeinstellung, aber Websites können weiterhin eine Richtlinie ihrer Wahl festlegen.
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 ansehen.
Neben der Referrer-Richtlinie kann sich auch die Art und Weise ändern, wie Browser mit Referrern umgehen. Behalten Sie das im Blick.

Was ändert sich und was ist der Grund dafür?

HTTP-Anfragen können den optionalen Referer-Header enthalten, der den Ursprung oder die URL der Webseite angibt, von der die Anfrage gesendet wurde. Im Referer-Policy-Header wird definiert, welche Daten im Referer-Header und für die Navigation und iFrames im document.referrer des Ziels verfügbar sind.

Welche Informationen genau im Referer-Header einer Anfrage von Ihrer Website gesendet werden, hängt vom Referrer-Policy-Header ab, den Sie festlegen.

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

Wenn keine Richtlinie festgelegt ist, wird die Standardeinstellung des Browsers verwendet. Websites verwenden oft die Standardeinstellung des Browsers.

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

Bis vor Kurzem war no-referrer-when-downgrade eine weitverbreitete Standardrichtlinie für Browser. Viele Browser befinden sich jedoch in einer Phase, in der datenschutzfreundlichere Standardeinstellungen eingeführt werden.

In Chrome soll die Standardrichtlinie no-referrer-when-downgrade in strict-origin-when-cross-origin geändert werden. Ab Version 85 wird die Änderung eingeführt.

Wenn für Ihre Website keine Richtlinie 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 ist.

Was bedeutet diese Änderung?

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

So wird verhindert, dass private Daten, auf die über andere Teile der vollständigen URL wie den Pfad und den Abfragestring zugegriffen werden kann, offengelegt werden.

Diagramm: Der Referer wird je nach Richtlinie für eine ursprungsübergreifende Anfrage gesendet. — *Referer wird für eine ursprungsübergreifende Anfrage gesendet (und document.referrer), je nach 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: 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 strict-origin-when-cross-origin sicher: Wenn die Anfrage von einem HTTPS-Ursprung (sicher) an einen HTTP-Ursprung (unsicher) gesendet wird, ist kein Referrer (Referer-Header und document.referrer) vorhanden. Wenn Ihre Website HTTPS verwendet (falls nicht, sollten Sie das unbedingt nachholen), werden die URLs Ihrer Website nicht in Nicht-HTTPS-Anfragen weitergegeben. Da diese Anfragen von jedem im Netzwerk eingesehen werden können, wären Ihre Nutzer sonst Man-in-the-Middle-Angriffen ausgesetzt.
Innerhalb desselben Ursprungs ist der Headerwert Referer die vollständige URL.

Beispiel: Anfrage mit demselben Ursprung, die von https://site-one.example/stuff/detail?tag=red an https://site-one.example/… gesendet wird:

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

Welche Auswirkungen hat das?

Basierend auf Gesprächen mit anderen Browsern und dem eigenen Testlauf von Chrome in Chrome 84 dürften für Nutzer sichtbare Fehler nur in begrenztem Umfang auftreten.

Die serverseitige Protokollierung oder Analyse, die auf der vollständigen Verweis-URL basiert, ist wahrscheinlich von der geringeren Granularität dieser Informationen betroffen.

Was muss ich tun?

Die neue Standard-Verweisrichtlinie soll mit Chrome 85 eingeführt werden (Juli 2020 für die Betaversion, August 2020 für die stabile Version). Den Status finden Sie im Chrome-Statuseintrag.

Änderung verstehen und erkennen

In dieser Demo können Sie sich ansehen, wie sich die neuen Standardänderungen in der Praxis auswirken.

Mit dieser Demo können Sie auch erkennen, welche Richtlinie in der Chrome-Instanz angewendet wird, die Sie ausführen.

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

Sie können die Änderung bereits ab Chrome 81 ausprobieren: Rufen Sie chrome://flags/#reduced-referrer-granularity in Chrome auf und aktivieren Sie das Flag. Wenn dieses Flag aktiviert ist, wird für alle Websites ohne Richtlinie der neue strict-origin-when-cross-origin-Standardwert 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 Backend verhalten.

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

Bestimmte Funktionen auf Ihrer Website funktionieren möglicherweise nicht mehr oder anders, wenn Sie den Referrer von Anfragen von einem anderen Ursprung an Ihre Website verwenden (insbesondere den Pfad und/oder den Query-String) UND dieser Ursprung die Standard-Referrer-Richtlinie des Browsers verwendet (d.h. keine Richtlinie festgelegt ist).

Wenn sich das auf Ihre Website auswirkt, sollten Sie über Alternativen nachdenken.

Wenn Sie den Referrer verwenden, um auf den vollständigen Pfad oder Abfragestring für Anfragen an Ihre Website zuzugreifen, haben Sie folgende 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. Best Practices für Referer und Referrer-Policy
Sie können sich mit Partnern auf eine bestimmte Richtlinie einigen, wenn dies erforderlich und für Ihre Nutzer transparent ist. Die Zugriffssteuerung, bei der der Referrer von Websites verwendet wird, um anderen Ursprüngen bestimmten Zugriff auf ihre Ressourcen zu gewähren, könnte ein solcher Fall sein. Durch die Änderung in Chrome wird der Ursprung jedoch weiterhin im Referer-Header (und in document.referrer) geteilt.

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

Eine explizite, datenschutzfreundliche Richtlinie auf Ihrer Website implementieren

Welche Referer sollten in Anfragen gesendet werden, die von Ihrer Website stammen, d.h. welche Richtlinie sollten Sie für Ihre Website festlegen?

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

Das schützt Ihre Nutzer und sorgt dafür, dass sich Ihre Website in verschiedenen Browsern vorhersehbarer verhält. Meistens haben Sie dadurch mehr Kontrolle, anstatt sich auf Browserstandardeinstellungen zu verlassen.

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

Chrome Enterprise

Die Chrome Enterprise-Richtlinie ForceLegacyDefaultReferrerPolicy ist für IT-Administratoren verfügbar, die die vorherige standardmäßige 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

Möchten Sie uns Feedback geben oder etwas melden? Feedback zu den Versandabsichten von Chrome geben oder Fragen an @maudnals twittern.

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.