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łówekReferrer-Policy
ireferrer
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
.
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.
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łówekReferer
idocument.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
.
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
iSec-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 elemenciedocument.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.