Nowa domyślna zasada odsyłająca dla Chrome – strict-origin-when-cross-origin.

Maud Nalpas
Maud Nalpas
X GitHub

Zanim zaczniemy:

Podsumowanie

  • Przeglądarki ewoluują w kierunku domyślnych zasad dotyczących strony odsyłającej, które zwiększają prywatność, aby zapewnić dobre rozwiązanie zastępcze, gdy witryna nie ma ustawionych zasad.
  • Chrome planuje stopniowe włączanie zasady strict-origin-when-cross-origin jako domyślnej w wersji 85. Może to mieć wpływ na przypadki użycia oparte na wartości strony odsyłającej z innego źródła.
  • Jest to nowe ustawienie domyślne, ale strony internetowe mogą nadal wybierać zasady według własnego uznania.
  • Aby wypróbować tę zmianę w Chrome, włącz flagę na stronie chrome://flags/#reduced-referrer-granularity. Możesz też obejrzeć to demo, aby zobaczyć, jak działa ta funkcja.
  • Oprócz zasad dotyczących odesłań może się zmienić sposób, w jaki przeglądarki obsługują odesłania – warto więc śledzić tę kwestię.

Co się zmienia i dlaczego?

Żądania HTTP mogą zawierać opcjonalny nagłówek Referer, który wskazuje źródło lub adres URL strony internetowej, z której wysłano żądanie. Nagłówek Referer-Policy określa, jakie dane są dostępne w nagłówku Referer oraz w ramkach nawigacyjnych i iframe w miejscu docelowym document.referrer.

Dokładne informacje wysyłane w nagłówku Referer w żądaniu z Twojej witryny zależą od ustawionego przez Ciebie nagłówka Referrer-Policy.

Diagram: Odsyłacz wysłany w żądaniu
Referrer-Policy i Referer.

Jeśli nie skonfigurowano żadnej zasady, używana jest domyślna zasada przeglądarki. Witryny często korzystają z ustawień domyślnych przeglądarki.

W przypadku nawigacji i elementów iframe dane w nagłówku Referer można też uzyskać za pomocą kodu JavaScript za pomocą document.referrer.

Do niedawna no-referrer-when-downgradebyła powszechną domyślną zasadą w przypadku wszystkich przeglądarek. Obecnie wiele przeglądarek jest na różnych etapach przechodzenia na domyślne ustawienia zwiększające prywatność.

Chrome planuje zmienić domyślną zasadę z no-referrer-when-downgrade na strict-origin-when-cross-origin począwszy od wersji 85.

Oznacza to, że jeśli nie ustawisz zasad dla swojej witryny, Chrome będzie domyślnie używać wartości strict-origin-when-cross-origin. Pamiętaj, że nadal możesz ustawić wybraną przez siebie zasadę. Ta zmiana będzie miała wpływ tylko na witryny, w których nie ma ustawionej zasady.

Co oznacza ta zmiana?

strict-origin-when-cross-origin zapewnia większą prywatność. W ramach tej zasady w nagłówku Referer żądań między domenami jest wysyłana tylko pochodzenie.

Zapobiega to wyciekom danych prywatnych, które mogą być dostępne z innych części pełnego adresu URL, takich jak ścieżka i ciąg znaków zapytania.

Diagram: odesłanie referrera w zależności od zasad dotyczących żądania między domenami.
Referer (i document.referrer) wysyłany w przypadku żądania z innej domeny w zależności od zasad.

Na przykład:

Żądanie z innego źródła wysłane z adresu https://site-one.example/stuff/detail?tag=red do adresu https://site-two.example/…:

  • Z no-referrer-when-downgrade: odnośnik: https://site-one.example/stuff/detail?tag=red.
  • Z strict-origin-when-cross-origin: odesłanie: https://site-one.example/.

Co pozostaje bez zmian?

  • Podobnie jak no-referrer-when-downgrade, strict-origin-when-cross-origin jest bezpieczny: nie ma odsyłacza (nagłówka Referer ani parametru document.referrer), gdy żądanie jest wysyłane z źródła HTTPS (bezpieczne) do źródła HTTP (niebezpieczne). Jeśli Twoja witryna korzysta z protokołu HTTPS (jeśli nie, zrób to priorytetem), adresy URL Twojej witryny nie będą widoczne w żądaniach niebędących HTTPS, ponieważ mogą je zobaczyć wszyscy w sieci, co naraża użytkowników na ataki typu „człowiek w środku”.
  • W ramach tego samego źródła wartość nagłówka Referer to pełny adres URL.

Na przykład: żądanie z tego samego źródła wysłane z adresu https://site-one.example/stuff/detail?tag=red do adresu https://site-one.example/…:

  • Z strict-origin-when-cross-origin: referrer: https://site-one.example/stuff/detail?tag=red

Jakie są konsekwencje?

Na podstawie rozmów z twórcami innych przeglądarek oraz własnych eksperymentów przeprowadzonych w Chrome 84 oczekujemy, że widoczne dla użytkowników problemy będą ograniczone.

Na logowaniu po stronie serwera lub usługach analitycznych, które polegają na dostępności pełnego adresu URL witryny powołującej, prawdopodobnie wpłynie zmniejszenie szczegółowości tych informacji.

Co trzeba zrobić?

Chrome zamierza wdrożyć nowe domyślne zasady dotyczące stron odsyłających w wersji 85 (w lipcu 2020 r. w wersji beta, a w sierpniu 2020 r. w wersji stabilnej). Stan usługi znajdziesz w pliku z informacjami o stanie Chrome.

Interpretowanie i wykrywanie zmiany

Aby dowiedzieć się, jak nowe domyślne zmiany wpłyną na Twoją praktykę, obejrzyj to demo.

Możesz też użyć tej wersji demonstracyjnej, aby sprawdzić, jaka zasada jest stosowana w uruchomionym wystąpieniu Chrome.

Testowanie zmiany i sprawdzanie, czy wpłynie ona na Twoją witrynę

Możesz już wypróbować tę zmianę, zaczynając od Chrome 81: otwórz chrome://flags/#reduced-referrer-granularity w Chrome i włącz flagę. Gdy ten parametr jest włączony, wszystkie witryny bez zasad będą używać domyślnej wartości strict-origin-when-cross-origin.

Zrzut ekranu z Chrome: jak włączyć flagę chrome://flags/#reduced-referrer-granularity.
Włączanie flagi.

Możesz teraz sprawdzić, jak działa Twoja witryna i back-end.

Aby wykryć wpływ, możesz też sprawdzić, czy kod źródłowy Twojej witryny używa parametru odesłania – za pomocą nagłówka Referer przychodzących żądań na serwerze lub za pomocą funkcji document.referrer w JavaScript.

Niektóre funkcje w Twojej witrynie mogą przestać działać lub zachowywać się inaczej, jeśli używasz odesłania z innego źródła do Twojej witryny (a ściślej mówiąc ścieżki lub ciągu znaków zapytania) i to źródło używa domyślnej polityki odesłania przeglądarki (czyli nie ma ustawionej żadnej polityki).

Jeśli to ma wpływ na Twoją witrynę, rozważ inne rozwiązania

Jeśli używasz strony odsyłającej, aby uzyskać dostęp do pełnej ścieżki lub ciągu znaków zapytania w przypadku żądań wysyłanych do Twojej witryny, masz kilka opcji:

  • Używaj alternatywnych technik i nagłówków, takich jak Origin i Sec-fetch-Site, do ochrony przed atakami CSRF, rejestrowania i innych zastosowań. Zapoznaj się ze sprawdzonymi metodami dotyczącymi odwołania i odpowiedniej polityki.
  • Jeśli to konieczne i jeśli użytkownicy są o tym poinformowani, możesz uzgodnić z partnerami określone zasady. Może to być kontrola dostępu – gdy witryny używają strony odsyłającej, aby przyznać określony dostęp do swoich zasobów innym źródłom. Po zmianie w Chrome źródło nadal będzie udostępniane w głównym nagłówku Referer (i w document.referrer).

Pamiętaj, że większość przeglądarek podąża w podobnym kierunku, jeśli chodzi o odwołania (zobacz domyślne ustawienia przeglądarki i ich ewolucję w artykule Odwołania i zasady dotyczące odsyłaczy: sprawdzone metody).

wdrożyć w swojej witrynie wyraźną politykę zwiększającą prywatność;

Jakie wartości Referer powinny być wysyłane w żądaniach wywoływanych przez Twoją witrynę, czyli jakie zasady należy ustawić w witrynie?

Mimo zmian w Chrome warto już teraz ustawić wyraźne zasady zwiększające prywatność, takie jak strict-origin-when-cross-origin lub jeszcze bardziej restrykcyjne.

Chroni to użytkowników i zapewnia większą przewidywalność działania witryny w różnych przeglądarkach. Przede wszystkim daje Ci kontrolę nad tym, co się dzieje w witrynie, zamiast polegać na domyślnych ustawieniach przeglądarki.

Więcej informacji o ustawianiu zasad znajdziesz w artykule „Referer i zasady dotyczące referrera: sprawdzone metody”.

Informacje o Chrome Enterprise

Zasada przedsiębiorstwa Chrome ForceLegacyDefaultReferrerPolicy jest dostępna dla administratorów IT, którzy chcą w środowiskach przedsiębiorstwa wymusić poprzednie domyślne zasady dotyczące strony odsyłającej no-referrer-when-downgrade. Dzięki temu firmy mają więcej czasu na przetestowanie i zaktualizowanie swoich aplikacji.

Ta zasada zostanie usunięta w Chrome 88.

Prześlij opinię

Czy chcesz się podzielić opinią lub zgłosić coś ważnego? Prześlij opinię na temat planów dotyczących wprowadzenia Chrome na rynek lub prześlij pytania na Twitterze do @maudnals.

Dziękujemy wszystkim recenzentom za ich wkład i opinie, zwłaszcza Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck i Kayce Basques.

Zasoby