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 „site” a „origin”, zapoznaj się z artykułem na temat wyników „same-site” i „same-origin”.
W nagłówku Referer brakuje litery R z powodu oryginalnego błędu pisowni w specyfikacji. Nagłówek Referrer-Policy i referrer w JavaScript oraz DOM są zapisane poprawnie.

Podsumowanie

Przeglądarki wdrażają nowe, zwiększające prywatność zasady dotyczące stron odsyłających, aby zapewnić dobre działanie w sytuacjach, gdy witryna nie ma określonych zasad.
Planujemy stopniowo włączać strict-origin-when-cross-origin jako domyślną zasadę w wersji 85 Chrome. Może to wpłynąć na przypadki użycia, w których użycie wartości strony odsyłającej z innego źródła może mieć wpływ.
To jest nowe ustawienie domyślne, ale witryny nadal mogą wybrać dowolne zasady.
Aby wypróbować tę zmianę w Chrome, włącz flagę na chrome://flags/#reduced-referrer-granularity. Jeśli chcesz zobaczyć, jak to działa, możesz też obejrzeć tę prezentację.
Sposób traktowania stron odsyłających przez przeglądarki może ulec zmianie, nie tylko w zasadach dotyczących stron odsyłających, więc warto zwracać na to uwagę.

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órego wysłano żądanie. Nagłówek Referer-Policy określa, jakie dane są udostępniane w nagłówku Referer oraz na potrzeby nawigacji i elementów iframe w elemencie document.referrer miejsca docelowego.

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

Diagram: strona odsyłająca wysłana w żądaniu. — *Zasada odsyłająca i strona odsyłająca.*

Gdy zasada nie jest skonfigurowana, używane są ustawienia domyślne przeglądarki. Strony często uzależniają się od przeglądarki domyślnej.

W przypadku elementów nawigacyjnych i elementów iframe dane w nagłówku Referer są też dostępne za pomocą JavaScriptu, który używa document.referrer.

Do niedawna zasady no-referrer-when-downgrade były powszechnie stosowane w przeglądarkach. Jednak obecnie wiele przeglądarek jest na etapie przechodzenia na bardziej szczegółowe ustawienia, które zwiększają prywatność.

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

Oznacza to, że jeśli w witrynie nie ustawiono żadnej zasady, Chrome będzie domyślnie używać strict-origin-when-cross-origin. Nadal możesz ustawić wybrane zasady – zmiana będzie dotyczyć tylko witryn, które nie mają ustawionych zasad.

Co oznacza ta zmiana?

strict-origin-when-cross-origin oferuje więcej prywatności. Zgodnie z tą zasadą w nagłówku Referer żądań z innych domen jest wysyłana tylko wartość origin.

Zapobiega to wyciekom prywatnych danych, które mogą być dostępne z innych części pełnego adresu URL, np. ścieżki i ciągu zapytania.

Diagram: w zależności od zasady wysyłana jest strona odsyłająca dla żądania z innej domeny. — *W zależności od zasady wysłano stronę odsyłającą (i document.referrer) w przypadku żądania z innej domeny.*

Na przykład:

Żądanie z innej domeny wysyłane z https://site-one.example/stuff/detail?tag=red na https://site-2.example/...:

W elemencie no-referrer-when-downgrade: strona odsyłająca: https://site-one.example/stuff/detail?tag=red.
Za pomocą strict-origin-when-cross-origin: strona odsyłająca: https://site-one.example/.

Co pozostaje bez zmian?

Podobnie jak no-referrer-when-downgrade, element strict-origin-when-cross-origin jest zabezpieczony: brak strony odsyłającej (nagłówka Referer i document.referrer), gdy żądanie jest wysyłane z źródła HTTPS (bezpiecznego) do HTTP (niezabezpieczone). Dzięki temu, jeśli witryna korzysta z protokołu HTTPS (jeśli nie, to potraktuj go priorytetowo), adresy URL z niej nie wycieknie w żądaniach niezgodnych z protokołem HTTPS. Każdy użytkownik w sieci będzie mógł je zobaczyć, a to naraża użytkowników na ataki typu „man in the middle”.
W obrębie tego samego pochodzenia wartość nagłówka Referer jest pełnym adresem URL.

Na przykład: Żądanie z tej samej domeny wysyłane z adresu https://site-one.example/stuff/detail?tag=red na https://site-one.example/...:

Za pomocą atrybutu strict-origin-when-cross-origin: strona odsyłająca: https://site-one.example/stuff/detail?tag=red

Efekty

Z dyskusji na temat innych przeglądarek oraz z eksperymentów przeprowadzonych przez Chrome w Chrome 84 wynika, że awarie widoczne dla użytkowników powinny być ograniczone.

Mniej szczegółowe informacje mogą mieć wpływ na logowanie lub analizy po stronie serwera, które polegają na pełnym dostępnym adresie URL strony odsyłającej.

Co trzeba zrobić?

Nowe domyślne zasady dotyczące stron odsyłających w Chrome planujemy rozpocząć w wersji 85 (wersja beta w lipcu 2020 r., sierpień 2020 r. w przypadku wersji stabilnej). Sprawdź stan we wpisie o stanie Chrome.

Zrozumienie i wykrywanie zmiany

Aby dowiedzieć się, jak w praktyce obowiązują nowe domyślne zmiany, obejrzyj tę prezentację.

Możesz też skorzystać z tej wersji demonstracyjnej, aby wykryć zasady stosowane w uruchomionej instancji Chrome.

Przetestuj zmianę i zobacz, czy będzie miała wpływ na Twoją witrynę.

Możesz już wypróbować tę zmianę od Chrome 81. Aby to zrobić, otwórz w Chrome stronę chrome://flags/#reduced-referrer-granularity i włącz tę flagę. Gdy ta flaga jest włączona, wszystkie witryny bez zasady używają nowej wartości domyślnej strict-origin-when-cross-origin.

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

Możesz teraz sprawdzać, jak zachowuje się Twoja witryna i backend.

Aby wykryć wpływ, sprawdź też, czy baza kodu Twojej witryny korzysta z strony odsyłającej – za pośrednictwem nagłówka Referer żądań przychodzących na serwerze lub z document.referrer w JavaScript.

Niektóre funkcje w Twojej witrynie mogą działać nieprawidłowo lub działać inaczej, jeśli do witryny jest używana strona odsyłająca z innego źródła (a dokładniej ścieżki lub ciągu zapytania) ORAZ ten punkt początkowy używa domyślnych zasad dotyczących stron odsyłających w przeglądarce (czyli nie ma ustawionych zasad).

Jeśli ma to wpływ na Twoją witrynę, rozważ inne możliwości

Jeśli używasz strony odsyłającej do uzyskiwania dostępu do pełnej ścieżki lub ciągu zapytania dla żądań kierowanych do Twojej witryny, masz kilka możliwości:

Aby zapewnić ochronę przed żądaniem CSRF, logowanie i w innych przypadkach użycia, używaj alternatywnych technik i nagłówków, takich jak Origin i Sec-fetch-Site. Zapoznaj się ze sprawdzonymi metodami dotyczącymi witryn odsyłających i witryn odsyłających.
Możesz uzgodnić z partnerami konkretne zasady, jeśli jest to konieczne i w sposób przejrzysty dla użytkowników. Kontrola dostępu – gdy strona odsyłająca jest używana przez witryny do przyznawania określonym źródłom dostępu do ich zasobów innym źródłom, może tak być, chociaż po zmianie Chrome źródło będzie nadal udostępniane w nagłówku Referer (i w document.referrer).

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

Wprowadź w swojej witrynie jednoznaczne zasady, które będą zgodne z zasadami ochrony prywatności

Jakie parametry Referer powinny być wysyłane w żądaniach pochodzących z Twojej witryny (czyli jakie zasady należy ustawić dla witryny)?

Nawet jeśli zmieniasz zasady Chrome, warto ustawić wyraźną, ulepszającą prywatność zasadę, np. strict-origin-when-cross-origin, lub bardziej rygorystycznie.

Pozwala to chronić użytkowników i sprawi, że działanie witryny w różnych przeglądarkach będzie bardziej przewidywalne. Głównie jednak rozwiązanie to daje Ci pełną kontrolę nad działaniem witryny, nie zależnie od ustawień domyślnych przeglądarki.

Więcej informacji o ustawianiu zasad znajdziesz w artykule Zasady dotyczące stron odsyłających i witryn odsyłających: sprawdzone metody.

Informacje o Chrome Enterprise

Zasady Chrome dla firm ForceLegacyDefaultReferrerPolicy są dostępne dla administratorów IT, którzy chcą wymusić stosowanie poprzednich domyślnych zasad dotyczących stron odsyłających no-referrer-when-downgrade w środowiskach firmowych. Dzięki temu firmy zyskują 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ć coś nowego? Podziel się opinią o zamiarach Chrome na dostawę lub wyślij tweeta z pytaniami na adres @maudnals.

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