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

Maud Nalpas
Maud Nalpas

Zanim zaczniemy:

  • Jeśli nie masz pewności, czym różnią się wartości „site” i „origin”, zapoznaj się z definicją wartości „same-site” i „same-origin”.
  • W nagłówku Referer brakuje znaku R z powodu oryginalnego błędu w specyfikacji. Nagłówek Referrer-Policy i referrer w języku JavaScript i DOM mają prawidłową pisownię.

Podsumowanie

  • Przeglądarki rozwijają się w kierunku stosowania domyślnych zasad dotyczących stron odsyłających, które zapewniają ochronę prywatności użytkowników, gdy witryna nie ma ustawionych zasad.
  • Chrome zamierza stopniowo włączyć strict-origin-when-cross-origin jako zasadę domyślną w wersji 85. Może to mieć wpływ na przypadki użycia związane z korzystaniem z wartości strony odsyłającej z innego źródła.
  • Jest to nowe ustawienie domyślne, ale witryny nadal mogą wybierać dowolne zasady.
  • Aby wypróbować tę zmianę w Chrome, włącz flagę na stronie chrome://flags/#reduced-referrer-granularity. Możesz też zobaczyć tę prezentację, żeby zobaczyć, jak to wygląda w praktyce.
  • Oprócz zasady dotyczącej stron odsyłających sposób, w jaki przeglądarki obsługują takie strony, może się zmienić, więc warto na to zwrócić uwagę.

Co się zmienia i dlaczego?

Żądania HTTP mogą zawierać opcjonalny nagłówek Referer, który wskazuje adres URL źródła lub strony internetowej, z której 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 nagłówka Referrer-Policy.

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

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

W przypadku elementów nawigacyjnych i elementów iframe dane zawarte w nagłówku Referer są też dostępne przez JavaScript za pomocą funkcji document.referrer.

Do niedawna zasada no-referrer-when-downgrade była bardzo powszechną zasadą domyślną w różnych przeglądarkach. Obecnie wiele przeglądarek jest na etapie przechodzenia na domyślne ustawienia zapewniające większą prywatność.

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

Oznacza to, że jeśli dla witryny nie jest skonfigurowana żadna zasada, Chrome domyślnie używa strict-origin-when-cross-origin. Pamiętaj, że nadal możesz ustawić dowolną zasadę. Ta zmiana będzie miała wpływ tylko na witryny, które nie mają ustawionych zasad.

Co oznacza ta zmiana?

strict-origin-when-cross-origin zapewnia większą prywatność. Dzięki tej zasadzie w nagłówku Referer w żądaniach z innych domen jest wysyłany tylko parametr origin.

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

Diagram: strona odsyłająca została wysłana (w zależności od zasady) w przypadku żądania z innej domeny.
W zależności od zasady została wysłana strona odsyłająca (i dokument.referrer) w przypadku żądania z innej domeny.

Na przykład:

Żądanie dotyczące innych domen, wysłane z adresu https://site-one.example/stuff/detail?tag=red na https://site-two.example/...:

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

Co się nie zmienia?

  • Podobnie jak no-referrer-when-downgrade, strict-origin-when-cross-origin jest zabezpieczony: brak strony odsyłającej (nagłówek Referer i document.referrer), gdy żądanie jest wysyłane ze źródła HTTPS (bezpiecznego) do źródła HTTP (niezabezpieczonego). Dzięki temu, jeśli witryna korzysta z protokołu HTTPS (jeśli nie jest, należy nadać jej priorytet), adresy URL witryny nie będą ujawniane w żądaniach innych niż HTTPS, ponieważ każdy w sieci może je zobaczyć, co narazi użytkowników na ataki typu „man in the middle”.
  • W tym samym źródle wartość nagłówka Referer to pełny adres URL.

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

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

Skutki:

Na podstawie dyskusji z innymi przeglądarkami oraz eksperymentów prowadzonych w Chrome w wersji 84 spodziewane jest ograniczenie widocznych dla użytkowników elementów zakłócających.

Logowanie po stronie serwera i statystyki, które bazują na pełnym adresie URL strony odsyłającej, mogą mieć wpływ na mniejszą szczegółowość tych informacji.

Co trzeba zrobić?

Nowe domyślne zasady dotyczące stron odsyłających pojawią się w Chrome w dniu 85 lat (lipiec 2020 r. w przypadku wersji beta, sierpień 2020 r. w przypadku wersji stabilnej). Sprawdź stan we wpisie o stanie Chrome.

Zrozumienie i wykrywanie zmiany

Aby dowiedzieć się, jak nowe domyślne zmiany w praktyce wchodzą w życie, obejrzyj tę prezentację.

Możesz też zobaczyć, jaka zasada jest stosowana w uruchomionej instancji Chrome.

Przetestuj zmianę i zastanów się, czy wpłynie to na Twoją witrynę.

Możesz już wypróbować tę zmianę, począwszy od Chrome 81: otwórz w Chrome stronę chrome://flags/#reduced-referrer-granularity i włącz flagę. Gdy ta flaga jest włączona, wszystkie witryny bez zasady będą używać 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 sprawdzić, jak zachowuje się Twoja witryna i backend.

Innym sposobem na wykrycie wpływu jest sprawdzenie, czy baza kodu Twojej witryny korzysta ze strony odsyłającej – w nagłówku Referer przychodzących żądań na serwerze czy z document.referrer w JavaScript.

Niektóre funkcje Twojej witryny mogą działać nieprawidłowo, jeśli używasz strony odsyłającej żądań z innego źródła (a konkretnie ze ścieżki lub ciągu zapytania) ORAZ to źródło używa domyślnych zasad przeglądarki dotyczących stron odsyłających (czyli nie skonfigurowano zasad).

Jeśli ma to 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 zapytania w przypadku żądań kierowanych do Twojej witryny, masz kilka możliwości:

  • Na potrzeby ochrony CSRF, logowania danych i innych przypadków użycia używaj alternatywnych metod i nagłówków, takich jak Origin i Sec-fetch-Site. Zapoznaj się ze sprawdzonymi metodami dotyczącymi odsyłania i zasad dotyczących stron odsyłających.
  • Jeśli jest to potrzebne i przejrzyste dla użytkowników, możesz uzgodnić z partnerem konkretne zasady. Kontrola dostępu – może tak być, gdy strona odsyłająca jest używana przez witryny do przyznawania określonych uprawnień dostępu do ich zasobów innym źródłom. Po wprowadzeniu zmian w Chrome źródło będzie nadal udostępniane w nagłówku Referer (i w elemencie document.referrer).

Jeśli chodzi o stronę odsyłającą, większość przeglądarek zmierza w podobnym kierunku (zobacz informacje o ustawieniach domyślnych przeglądarki i ich ewolucjach w artykule Sprawdzone metody dotyczące zasad odsyłających i witryn odsyłających).

Wdróż w swojej witrynie jednoznaczne zasady, które poprawią ochronę prywatności

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

Zmieniamy aplikację Chrome, jednak warto już teraz ustawić jednoznaczne zasady zwiększające prywatność, np. strict-origin-when-cross-origin lub bardziej rygorystyczne.

Chroni to użytkowników i sprawia, że działanie witryny jest bardziej przewidywalne w różnych przeglądarkach. Zasadniczo daje Ci kontrolę, a nie pozwala, aby strona była zależna od ustawień domyślnych przeglądarki.

Szczegółowe informacje o ustawianiu zasad znajdziesz w artykule Referrer and Referrer-Policy: sprawdzone metody.

Informacje o Chrome Enterprise

Zasada Chrome Enterprise ForceLegacyDefaultReferrerPolicy jest dostępna dla administratorów IT, którzy chcą wymusić poprzednią domyślną zasadę dotyczącą stron odsyłających (no-referrer-when-downgrade) w środowiskach firmowych. Dzięki temu firmy zyskują więcej czasu na testowanie i aktualizowanie swoich aplikacji.

Ta zasada zostanie usunięta w Chrome 88.

Prześlij opinię

Czy chcesz podzielić się opinią lub zgłosić coś do zgłoszenia? Podziel się opinią na temat zamiaru wysyłki Chrome lub wyślij tweeta z pytaniami na adres @maudnals.

Dziękujemy wszystkim weryfikatorom za publikowane treści i przekazywane opinie – zwłaszcza Kaustubha Govind, Davida Van Cleve, Mike'a Westa, Sama Duttona, Rowana Merewooda, Jxcka i Kayce Basquesa.

Zasoby