Bevor wir beginnen:
- Wenn Sie sich nicht sicher sind, was der Unterschied zwischen „Website“ und „Ursprung“ ist, lesen Sie den Hilfeartikel „Auf derselben Website“ und „Mit demselben Ursprung“.
- Im
Referer-Header fehlt ein R, da in der Spezifikation ursprünglich ein falsch geschriebenes R verwendet wurde. Die Schreibweise desReferrer-Policy-Headers und vonreferrerin JavaScript und im DOM ist korrekt.
Zusammenfassung
- Browser entwickeln sich in Richtung datenschutzfreundlicher standardmäßiger Verweisrichtlinien, um einen guten Fallback zu bieten, wenn für eine Website keine Richtlinie festgelegt ist.
- In Chrome wird
strict-origin-when-cross-originin Version 85 schrittweise als Standardrichtlinie aktiviert. Dies kann sich auf Anwendungsfälle auswirken, die auf den Verweiswert aus einer anderen Quelle angewiesen sind. - Dies ist die neue Standardeinstellung, Websites können aber weiterhin eine beliebige Richtlinie 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. - Abgesehen von der Verweis-Richtlinie kann sich auch die Art und Weise ändern, wie Browser mit Verweisquellen umgehen. Behalten Sie das im Auge.
Was ändert sich und warum?
HTTP-Anfragen können den optionalen Referer-Header enthalten, der die URL der Quelle oder der Webseite angibt, von der die Anfrage stammt. In der Referer-Policy-Überschrift wird festgelegt, welche Daten in der Referer-Überschrift und für die Navigation und iframes in der 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.
Wenn keine Richtlinie festgelegt ist, wird die Standardeinstellung des Browsers verwendet. Websites verwenden oft die Standardeinstellungen des Browsers.
Bei Navigationen und Iframes kann über document.referrer auch über JavaScript auf die Daten im Referer-Header zugegriffen werden.
Bis vor Kurzem war no-referrer-when-downgrade eine weit verbreitete Standardeinstellung in Browsern. Viele Browser befinden sich jedoch in der Phase der Umstellung auf datenschutzfreundlichere Standardeinstellungen.
In Chrome wird die Standardrichtlinie ab Version 85 von no-referrer-when-downgrade auf strict-origin-when-cross-origin umgestellt.
Wenn also 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 ist.
Was bedeutet diese Änderung?
strict-origin-when-cross-origin bietet mehr Datenschutz. Bei dieser Richtlinie wird nur der Ursprung im Referer-Header von ursprungsübergreifenden Anfragen gesendet.
So wird verhindert, dass private Daten gehackt werden, auf die über andere Teile der vollständigen URL wie den Pfad und den Suchstring zugegriffen werden kann.
Beispiel:
Ursprungsübergreifende Anfrage, gesendet von https://website-1.beispiel/stuff/detail?tag=rot an https://website-2.beispiel/…:
- Mit
no-referrer-when-downgrade: „Referer: https://website-1.beispiel.de/stuff/detail?tag=rot“ - Mit
strict-origin-when-cross-origin: „Referer: https://website-one.beispiel.de/“
Was bleibt gleich?
- Wie
no-referrer-when-downgradeist auchstrict-origin-when-cross-originsicher: Es ist kein Verweis (Referer-Header unddocument.referrer) vorhanden, wenn die Anfrage von einem HTTPS-Ursprung (sicher) an einen HTTP-Ursprung (unsicher) erfolgt. Wenn Ihre Website HTTPS verwendet (falls nicht, sollten Sie das ändern), werden die URLs Ihrer Website nicht in nicht-HTTPS-Anfragen weitergegeben, da diese von allen im Netzwerk gesehen werden können. Das würde Ihre Nutzer einem Man-in-the-Middle-Angriff aussetzen. - Innerhalb desselben Ursprungs ist der
Referer-Headerwert die vollständige URL.
Beispiel: Anfrage vom selben Ursprung, gesendet von https://website-1.beispiel.de/stuff/detail?tag=rot an https://website-1.beispiel.de/…:
- Mit
strict-origin-when-cross-origin: Referer: https://website-one.beispiel.de/stuff/detail?tag=rot
Welche Auswirkungen hat das?
Basierend auf Diskussionen mit anderen Browsern und eigenen Chrome-Tests in Chrome 84 sind für Nutzer sichtbare Probleme voraussichtlich begrenzt.
Serverseitige Protokollierung oder Analysen, die darauf angewiesen sind, dass die vollständige Verweis-URL verfügbar ist, sind wahrscheinlich von einer geringeren Detailgenauigkeit dieser Informationen betroffen.
Was muss ich tun?
Die neue Standard-Verweisrichtlinie soll in Chrome 85 eingeführt werden (Juli 2020 für die Betaversion, August 2020 für die stabile Version). Status im Chrome-Statuseintrag ansehen
Änderung verstehen und erkennen
In dieser Demo sehen Sie, wie sich die neuen Standardeinstellungen in der Praxis auswirken.
Mit dieser Demo können Sie auch feststellen, welche Richtlinie in der von Ihnen verwendeten Chrome-Instanz angewendet wird.
Testen Sie die Änderung und prüfen Sie, ob sich dies auf Ihre Website auswirkt
Sie können die Änderung bereits ab Chrome 81 ausprobieren: Rufen Sie dazu chrome://flags/#reduced-referrer-granularity in Chrome auf und aktivieren Sie die entsprechende Flag. Wenn dieses Flag aktiviert ist, wird für alle Websites ohne Richtlinie der neue Standardwert strict-origin-when-cross-origin verwendet.
Sie können jetzt prüfen, wie sich Ihre Website und Ihr Backend verhalten.
Sie können auch prüfen, ob die Codebasis Ihrer Website die Verweis-URL verwendet – 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 oder anders, wenn Sie den Verweis von Anfragen von einer anderen Quelle auf Ihre Website (genauer gesagt den Pfad und/oder den Suchstring) verwenden UND diese Quelle die Standardrichtlinie für Verweisquellen des Browsers verwendet (d.h., es ist keine Richtlinie festgelegt).
Wenn sich das auf Ihre Website auswirkt, sollten Sie Alternativen in Betracht ziehen.
Wenn Sie den Verweis 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
OriginundSec-fetch-Sitefür den CSRF-Schutz, die Protokollierung und andere Anwendungsfälle. Weitere Informationen finden Sie unter Best Practices für Referrer und Referrer-Policy. - Sie können sich mit Partnern über eine bestimmte Richtlinie abstimmen, wenn dies erforderlich und für Ihre Nutzer transparent ist.
Ein solcher Fall ist die Zugriffssteuerung, bei der der Referrer von Websites verwendet wird, um anderen Ursprüngen bestimmten Zugriff auf ihre Ressourcen zu gewähren. Nach der Änderung in Chrome wird der Ursprung jedoch weiterhin im
Referer-Header (und indocument.referrer) weitergegeben.
Die meisten Browser bewegen sich in Bezug auf den Verweisgeber in eine ähnliche Richtung. Weitere Informationen zu den Browserstandardeinstellungen und deren Entwicklung finden Sie unter Referrer und Referrer-Richtlinie: Best Practices.
Implementieren Sie eine eindeutige, datenschutzfreundliche Richtlinie auf Ihrer Website.
Welche Referer sollte in Anfragen gesendet werden, die von Ihrer Website stammen? Welche Richtlinie sollten Sie für Ihre Website festlegen?
Auch wenn Sie die Änderung in Chrome berücksichtigen, sollten Sie eine explizite, datenschutzfreundliche Richtlinie wie strict-origin-when-cross-origin oder strenger festlegen.
So werden Ihre Nutzer geschützt und die Website funktioniert in verschiedenen Browsern zuverlässiger. Vor allem haben Sie damit die Kontrolle, anstatt dass Ihre Website von den Browserstandardeinstellungen abhängt.
Weitere Informationen zum Festlegen einer Richtlinie finden Sie unter Best Practices für Verweis- und Verweisrichtlinien.
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
Hast du Feedback oder möchtest du etwas melden? Geben Sie Feedback zur Verfügbarkeit von ChromeOS oder senden Sie Ihre Fragen per Tweet an @maudnals.
Vielen Dank für die Beiträge und das Feedback aller Rezensenten, insbesondere von Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck und Kayce Basques.