Ta strona została przetłumaczona przez Cloud Translation API.

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

Maud Nalpas

Zanim zaczniemy:

Jeśli nie masz pewności, jaka jest różnica między „witryną” a „pochodzeniem”, przeczytaj artykuł Wyjaśnienie pojęć „ta sama witryna” i „to samo pochodzenie”.
W nagłówku Referer brakuje litery R z powodu błędu w specyfikacji. Nagłówek Referrer-Policy i referrer w JavaScript i DOM są zapisywane prawidłowo.

Podsumowanie

Przeglądarki zmierzają w kierunku domyślnych zasad dotyczących strony odsyłającej, które zwiększają prywatność, aby zapewnić odpowiednie rozwiązanie rezerwowe, gdy witryna nie ma ustawionych zasad.
Chrome planuje stopniowe włączanie strict-origin-when-cross-origin jako domyślnej zasady w wersji 85. Może to mieć wpływ na przypadki użycia, które opierają się na wartości strony odsyłającej z innego źródła.
Jest to nowe ustawienie domyślne, ale strony internetowe nadal mogą wybrać własne zasady.
Aby wypróbować tę zmianę w Chrome, włącz flagę na stronie chrome://flags/#reduced-referrer-granularity. Możesz też obejrzeć tę demonstrację, aby zobaczyć, jak działa ta zmiana.
Poza zasadami dotyczącymi odsyłającego sposób, w jaki przeglądarki obsługują odsyłających, może się zmienić, więc warto to śledzić.

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. Referer-Policy Nagłówek określa, jakie dane są dostępne w nagłówku Referer, a także w przypadku nawigacji i elementów iframe w document.referrer miejsca docelowego.

To, jakie informacje są wysyłane w nagłówku Referer w żądaniu z Twojej witryny, zależy od ustawionego nagłówka Referrer-Policy.

Diagram: adres URL strony odsyłającej wysłany w żądaniu. — *Zasada dotycząca strony odsyłającej i strona odsyłająca.*

Jeśli zasada nie jest skonfigurowana, używane jest ustawienie domyślne przeglądarki. Witryny często korzystają z domyślnych ustawień przeglądarki.

W przypadku nawigacji i elementów iframe dane znajdujące się w nagłówku Referer można też uzyskać za pomocą JavaScriptu przy użyciu document.referrer.

Do niedawna no-referrer-when-downgrade było domyślną zasadą w wielu przeglądarkach. Obecnie jednak wiele przeglądarek jest na etapie 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 od wersji 85.

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

Co oznacza ta zmiana?

strict-origin-when-cross-origin zapewnia większą prywatność. Zgodnie z tą zasadą w nagłówku Referer żądań pochodzących z innych domen wysyłany jest tylko punkt początkowy.

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 zapytania.

Diagram: nagłówek Referer wysyłany w zależności od zasady w przypadku żądania z innej domeny. — *W przypadku żądania z innego źródła wysyłany jest nagłówek Referer (i document.referrer) w zależności od zasad.*

Na przykład:

Żądanie z innej domeny wysłane z https://site-one.example/stuff/detail?tag=red do https://site-two.example/…:

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

Co pozostanie bez zmian?

Podobnie jak no-referrer-when-downgrade, strict-origin-when-cross-origin jest bezpieczny: gdy żądanie jest wysyłane z pochodzenia HTTPS (bezpiecznego) do pochodzenia HTTP (niebezpiecznego), nie ma odsyłającego adresu URL (nagłówka Referer i document.referrer). Dzięki temu, jeśli Twoja witryna korzysta z protokołu HTTPS (jeśli nie, potraktuj to priorytetowo), adresy URL witryny nie będą wyciekać w żądaniach innych niż HTTPS, ponieważ każdy w sieci może je zobaczyć, co naraża użytkowników na ataki typu „man-in-the-middle”.
W ramach tego samego źródła wartość nagłówka Referer to pełny adres URL.

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

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

Jakie są konsekwencje?

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

Zmniejszona szczegółowość tych informacji prawdopodobnie wpłynie na rejestrowanie po stronie serwera lub analizy, które opierają się na dostępności pełnego adresu URL strony odsyłającej.

Co trzeba zrobić?

Zespół Chrome planuje rozpocząć wdrażanie nowych domyślnych zasad dotyczących stron odsyłających w wersji 85 (w lipcu 2020 r. w przypadku wersji beta, w sierpniu 2020 r. w przypadku wersji stabilnej). Stan znajdziesz we wpisie stanu Chrome.

Omówienie i wykrywanie zmiany

Aby dowiedzieć się, jak nowe ustawienia domyślne działają w praktyce, obejrzyj to demo.

Możesz też użyć tej wersji demonstracyjnej, aby wykryć, która zasada jest stosowana w używanej instancji Chrome.

Sprawdź zmianę i zastanów się, czy będzie miała wpływ na Twoją witrynę.

Możesz już wypróbować tę zmianę w Chrome 81: otwórz chrome://flags/#reduced-referrer-granularity w Chrome i włącz flagę. Gdy ten flag jest włączony, wszystkie witryny bez zasad będą używać nowego ustawienia domyślnego 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łają Twoja witryna i jej zaplecze.

Aby wykryć wpływ, możesz też sprawdzić, czy baza kodu Twojej witryny używa odsyłającego – za pomocą nagłówka Referer w przychodzących żądaniach na serwerze lub za pomocą document.referrer w JavaScript.

Niektóre funkcje w Twojej witrynie mogą nie działać lub zachowywać się inaczej, jeśli używasz odsyłającego w przypadku żądań z innego źródła do Twojej witryny (a dokładniej ścieżki lub ciągu zapytania) ORAZ to źródło używa domyślnej polityki odsyłającego w przeglądarce (czyli nie ma ustawionej polityki).

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

Jeśli używasz strony odsyłającej, aby uzyskać pełną ścieżkę lub ciąg zapytania w przypadku żądań kierowanych do Twojej witryny, masz kilka możliwości:

W przypadku ochrony przed CSRF, rejestrowania i innych zastosowań używaj alternatywnych technik i nagłówków, takich jak Origin i Sec-fetch-Site. Zapoznaj się z artykułem Referer i Referrer-Policy: sprawdzone metody.
W razie potrzeby możesz uzgodnić z partnerami konkretne zasady, o ile będzie to przejrzyste dla użytkowników. Kontrola dostępu – gdy strona odsyłająca jest używana przez witryny do przyznawania określonego dostępu do ich zasobów innym źródłom – może być takim przypadkiem, chociaż po zmianie w Chrome źródło będzie nadal udostępniane w nagłówku Referer (i w document.referrer).

Pamiętaj, że większość przeglądarek zmierza w podobnym kierunku, jeśli chodzi o odsyłającego (zobacz ustawienia domyślne przeglądarek i ich ewolucję w artykule Referer i Referrer-Policy: sprawdzone metody).

Wdrożenie w witrynie wyraźnej polityki zwiększającej ochronę prywatności

Jakie Referer należy wysyłać w żądaniach pochodzących z Twojej witryny, czyli jakie zasady należy ustawić w przypadku witryny?

Nawet biorąc pod uwagę zmiany w Chrome, warto już teraz ustawić wyraźną politykę zwiększającą prywatność, np. strict-origin-when-cross-origin lub bardziej rygorystyczną.

Chroni to użytkowników i sprawia, że witryna działa bardziej przewidywalnie w różnych przeglądarkach. Zapewnia to przede wszystkim kontrolę nad witryną, zamiast polegać na ustawieniach domyślnych przeglądarki.

Więcej informacji o ustawianiu zasad znajdziesz w artykule Odesłanie i zasady dotyczące odesłania: sprawdzone metody.

Chrome Enterprise – informacje

Zasady Chrome EnterpriseForceLegacyDefaultReferrerPolicy są dostępne dla administratorów IT, którzy chcą wymusić poprzednie domyślne zasady dotyczące stron odsyłającychno-referrer-when-downgrade w środowiskach firmowych. Dzięki temu firmy mają więcej czasu na testowanie i aktualizowanie aplikacji.

Ta zasada zostanie usunięta w Chrome 88.

Prześlij opinię

Chcesz podzielić się opinią lub zgłosić problem? Podziel się opinią na temat planów Chrome dotyczących wprowadzenia zmian lub zadaj pytania na Twitterze, oznaczając @maudnals.

Dziękujemy wszystkim recenzentom za ich wkład i opinie, a w szczególności Kaustubha Govind, Davidowi Van Cleve, Mike’owi Westowi, Samowi Duttonowi, Rowanowi Merewoodowi, Jxckowi i Kayce Basques.