Czym jest Referrer-Policy?

Nagłówek HTTP Referrer-Policy kontroluje, ile informacji o oryginalnej stronie jest zawartych w nagłówku żądania Referer, gdy użytkownik nawiguje z Twojej strony na inną lub gdy Twoja strona ładuje zasoby z zewnętrznych źródeł. Za każdym razem, gdy ktoś klika link, za każdym razem, gdy obraz jest ładowany z CDN, za każdym razem, gdy uruchamia się skrypt analityczny, przeglądarka potencjalnie wysyła URL bieżącej strony do serwera docelowego. Z Referrer-Policy decydujesz, ile z tego URL-a udostępniasz.

(Krótka uwaga o pisowni: nagłówek HTTP jest pisany jako "Referer" z jednym "r" z powodu literówki w oryginalnej specyfikacji HTTP z początku lat dziewięćdziesiątych. Nagłówek polityki używa poprawnej pisowni "Referrer" z dwoma r. Obie pisownie są celowe.)

Co zawiera nagłówek Referer i kiedy jest wysyłany

Domyślnie (bez Referrer-Policy) przeglądarka wysyła pełny URL bieżącej strony jako nagłówek Referer w większości wychodzących żądań. Obejmuje to:

• Nawigację: gdy użytkownik klika link na inną stronę, miejsce docelowe otrzymuje pełny URL strony, z której przyszedł.
• Żądania podzasobów: gdy Twoja strona ładuje obrazy, skrypty, arkusze stylów lub fonty z zewnętrznych domen, każde żądanie zawiera nagłówek Referer.
• Wysyłki formularzy: gdy formularz wysyła dane na zewnętrzny URL, nagłówek Referer jest dołączany.
• Żądania AJAX i Fetch: wywołania API do usług zewnętrznych również domyślnie zawierają nagłówek Referer.

Załóżmy, że odwiedzający jest na tym URL Twojej witryny WordPress:

https://twojastrona.pl/czlonkowie/dashboard?session=abc123&plan=premium

Jeśli ta strona zawiera osadzony obraz od zewnętrznego dostawcy analityki lub sieci reklamowej, serwer tego dostawcy otrzymuje pełny URL w nagłówku Referer, włącznie z parametrami zapytania zawierającymi token sesji i informacje o planie. To jest obawa o prywatność, którą rozwiązuje Referrer-Policy.

Wszystkie wartości Referrer-Policy

Nagłówek Referrer-Policy obsługuje osiem różnych wartości. Każda definiuje inny poziom udostępniania informacji:

• no-referrer: nigdy nie wysyłaj nagłówka Referer. Miejsce docelowe nie otrzymuje żadnych informacji o tym, skąd przyszło żądanie. To najbardziej przyjazna prywatności opcja, ale może zepsuć funkcjonalność zależną od danych referrera (np. niektóre ochrony CSRF).
• no-referrer-when-downgrade: wysyłaj pełny URL, ale pomiń Referer podczas nawigacji z HTTPS na HTTP ("downgrade"). To była domyślna wartość przeglądarki przez lata. Chroni przed wyciekiem URL-i przy opuszczaniu bezpiecznego kontekstu, ale udostępnia wszystko podczas nawigacji HTTPS-do-HTTPS.
• origin: wysyłaj tylko origin (schemat, host i port), ale nie ścieżkę ani query string. Więc https://twojastrona.pl/czlonkowie/dashboard?session=abc123 staje się tylko https://twojastrona.pl/. Miejsce docelowe wie, z jakiej strony przyszedł odwiedzający, ale nie z jakiej konkretnej podstrony.
• origin-when-cross-origin: wysyłaj pełny URL dla żądań same-origin (linki w Twojej własnej witrynie), ale tylko origin dla żądań cross-origin. To daje Twojej własnej analityce i wewnętrznym narzędziom pełne dane referrera, ograniczając jednocześnie to, co widzą zewnętrzne strony.
• same-origin: wysyłaj pełny URL tylko dla żądań same-origin. Dla żądań cross-origin Referer w ogóle nie jest wysyłany. To bardzo prywatne dla zewnętrznej nawigacji, ale oznacza, że usługi zewnętrzne nie otrzymują danych referrera.
• strict-origin: wysyłaj tylko origin (jak w origin), ale całkowicie pomiń Referer podczas downgrade z HTTPS na HTTP. Łączy prywatność origin z ochroną downgrade no-referrer-when-downgrade.
• strict-origin-when-cross-origin: najczęściej zalecana wartość. Wysyła pełny URL dla żądań same-origin, tylko origin dla żądań cross-origin HTTPS-do-HTTPS, i nic podczas downgrade HTTPS-do-HTTP. To najlepsza równowaga między prywatnością, bezpieczeństwem i funkcjonalnością. Nowoczesne przeglądarki (Chrome 85+, Firefox 87+) wprowadziły to jako domyślne, nawet bez nagłówka Referrer-Policy.
• unsafe-url: zawsze wysyłaj pełny URL, niezależnie od miejsca docelowego lub kontekstu bezpieczeństwa. Nie nazywa się "unsafe" bez powodu. Wysyła parametry zapytania, ścieżki i wszystko inne, nawet do miejsc docelowych HTTP. Nigdy tego nie używaj, chyba że masz bardzo konkretną potrzebę i rozumiesz ryzyko.

Implikacje prywatności nagłówka Referer

Nagłówek Referer to ważna obawa o prywatność, którą wielu właścicieli stron przeocza. Pomyśl, jakie informacje mogą zawierać Twoje URL-e:

• Zapytania wyszukiwania: jeśli Twoja strona ma funkcję wyszukiwania, URL może wyglądać jak /search?q=wrazliwy+temat+zdrowotny. Każdy zewnętrzny zasób załadowany na stronie wyników wyszukiwania otrzymuje to zapytanie.
• Identyfikatory użytkowników: URL-e takie jak /user/jan-kowalski/profile lub /order/12345 wyciekają informacje o użytkownikach i zamówieniach stronom trzecim.
• Tokeny i dane sesji: niektóre aplikacje umieszczają tokeny w URL-ach dla resetów haseł, potwierdzeń email lub linków udostępniania. Mogą one wyciec przez nagłówek Referer.
• Wewnętrzna struktura URL: nawet sama struktura ścieżki (/wp-admin/, /tylko-czlonkowie/, /wewnetrzny-dashboard/) ujawnia informacje o architekturze Twojej strony.

Każdy zewnętrzny zasób na Twojej stronie jest potencjalnym odbiorcą tych informacji: Google Fonts, skrypty analityczne, przyciski mediów społecznościowych, osadzone filmy, sieci reklamowe, biblioteki hostowane na CDN i zewnętrzne obrazy. Każdy otrzymuje nagłówek Referer w swoich żądaniach.

Znaczenie dla RODO i ochrony danych

Pod RODO i podobnymi przepisami o prywatności URL-e z identyfikatorami osobowymi lub wrażliwymi informacjami mogą stanowić dane osobowe. Jeśli Twoje URL-e zawierają nazwy użytkowników, adresy email lub inne dane umożliwiające identyfikację, udostępnianie tych URL-i przez nagłówek Referer stronom trzecim może być problemem z ochroną danych.

Ustawienie Referrer-Policy to prosty środek techniczny, który zmniejsza niepotrzebne udostępnianie danych stronom trzecim. Choć nie jest wyraźnie wymagany przez RODO, jest zgodny z zasadami minimalizacji danych (art. 5(1)(c)) i privacy by design (art. 25). Jeśli Twój inspektor ochrony danych lub audyt prywatności pyta o środki techniczne wdrożone w celu ograniczenia wycieków danych, właściwa Referrer-Policy to konkretny element, do którego można się odwołać.

Domyślne zachowanie WordPressa i popularne wtyczki

Rdzeń WordPressa domyślnie nie ustawia nagłówka Referrer-Policy. Oznacza to, że Twoja strona polega na wbudowanym domyślnym ustawieniu przeglądarki. Dla nowoczesnych przeglądarek tym domyślnym ustawieniem jest strict-origin-when-cross-origin, co właściwie jest rozsądną polityką. Mimo to są kilka kwestii do rozważenia:

• Starsze przeglądarki mogą nadal wracać do no-referrer-when-downgrade, które wysyła pełny URL we wszystkich żądaniach HTTPS-do-HTTPS.
• Ustawienie nagłówka jawnie jest lepsze niż poleganie na domyślnych przeglądarek, ponieważ jasno komunikujesz swoją intencję i pokrywasz wszystkie wersje przeglądarek.
• Niektóre wtyczki bezpieczeństwa WordPressa (takie jak Sucuri lub iThemes Security) zawierają opcję Referrer-Policy w swoich ustawieniach hardeningu.
• WordPress 4.7.4 wprowadził ulepszenia funkcji wp_get_referer(), ale to funkcja po stronie serwera, która czyta nagłówek Referer dla ochrony CSRF. Jest oddzielna od nagłówka odpowiedzi Referrer-Policy.

Wpływ na analitykę witryny

Twój wybór Referrer-Policy bezpośrednio wpływa na to, jakie dane referrera otrzymują Twoje narzędzia analityczne i jakie dane otrzymują inne strony o ruchu z Twojej witryny:

• Twoja własna analityka: jeśli używasz Google Analytics, Matomo lub podobnego narzędzia ze skryptem śledzącym na Twojej stronie, żądania same-origin zawsze zawierają pełny referrer niezależnie od polityki (większość polityk ogranicza tylko cross-origin referrery). Twoje dane analityczne on-site nie są więc dotknięte przez większość wartości polityki.
• Śledzenie ruchu przychodzącego: Referrer-Policy, którą ustawiasz, wpływa na to, co widzą inne strony, gdy Twoi odwiedzający z nich przychodzą. Nie wpływa na to, co widzisz o ruchu przychodzącym do Twojej strony (to zależy od polityki strony odsyłającej).
• Śledzenie afiliacyjne i partnerów: jeśli masz program afiliacyjny lub musisz śledzić kliknięcia wychodzące, bardzo restrykcyjna polityka jak no-referrer zepsuje śledzenie oparte na referrerze. Zalecana wartość strict-origin-when-cross-origin wysyła origin (domenę) do partnerów, co zwykle wystarcza do atrybucji.

Ustawienie Referrer-Policy dla WordPressa

Zalecana wartość dla większości witryn WordPress to strict-origin-when-cross-origin:

Referrer-Policy: strict-origin-when-cross-origin

Ustawienie w Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

W Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Przez PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Jeśli Twoja strona przetwarza szczególnie wrażliwe dane (informacje medyczne, dane finansowe, dokumenty prawne), możesz rozważyć surowszą politykę, taką jak same-origin lub no-referrer. Po prostu pamiętaj, że to usunie informacje o referrerze dla wszystkich żądań cross-origin, co może wpłynąć na zewnętrzne usługi, które od nich zależą.

Co sprawdza InspectWP

InspectWP sprawdza, czy Twoja witryna WordPress wysyła nagłówek Referrer-Policy i raportuje skonfigurowaną wartość. Jeśli nagłówka brakuje, Twoja strona polega na domyślnym ustawieniu przeglądarki każdego odwiedzającego, które różni się między wersjami przeglądarek. Jawnie ustawiona Referrer-Policy zapewnia spójne zachowanie i pokazuje, że podjąłeś świadomą decyzję o tym, ile informacji o URL Twoja strona udostępnia stronom trzecim. Dla zdecydowanej większości witryn WordPress strict-origin-when-cross-origin jest zalecaną wartością.