Każdy plik cookie zawiera parę klucz-wartość i pewną liczbę atrybutów, które aby kontrolować, kiedy i gdzie taki plik jest używany.
Wprowadzenie atrybutu SameSite
(zdefiniowanym w
RFC6265bis)
pozwala zadeklarować, czy plik cookie jest ograniczony do pliku cookie
w kontekście tej samej witryny. Warto wiedzieć, czym dokładnie jest „strona” co znaczy tutaj.
Witryna składa się z sufiksu domeny i części domeny
wcześniej. Na przykład domena www.web.dev
jest częścią witryny web.dev
.
Kluczowe hasło: jeśli użytkownik korzysta z www.web.dev
i wysyła prośbę o obraz
static.web.dev
, to żądanie z tej samej witryny.
Lista domen publicznych określa, które strony są liczone jako
w tej samej witrynie. Nie zależy to tylko od domen najwyższego poziomu, takich jak .com
,
ale może również obejmować usługi takie jak github.io
. Dzięki temu
your-project.github.io
i my-project.github.io
, aby były liczone jako oddzielne witryny.
Kluczowe hasło: jeśli użytkownik korzysta z your-project.github.io
i wysyła prośbę o obraz
my-project.github.io
za pomocą żądania z innych witryn.
Użyj atrybutu SameSite
do zadeklarowania użycia plików cookie
Atrybut SameSite
w pliku cookie umożliwia sterowanie na 3 sposoby
tego zachowania. Możesz nie określać atrybutu lub użyć
Strict
lub Lax
, aby ograniczyć plik cookie do żądań z tej samej witryny.
Jeśli ustawisz SameSite
na Strict
, plik cookie może być wysyłany tylko
kontekst własny; czyli jeśli witryna z plikiem cookie pasuje do witryny
na pasku adresu przeglądarki. Jeśli więc plik cookie promo_shown
jest skonfigurowany w taki sposób:
Set-Cookie: promo_shown=1; SameSite=Strict
Gdy użytkownik odwiedza witrynę, plik cookie jest wysyłany z żądaniem zgodnie z oczekiwaniami.
Jeśli jednak użytkownik kliknie link do Twojej witryny z innej witryny, plik cookie
nie jest wysyłana w odpowiedzi na pierwsze żądanie.
To dobre rozwiązanie w przypadku plików cookie powiązanych z funkcjami, które zawsze są opóźnione
jak zmiana hasła czy dokonanie zakupu,
ograniczone w przypadku plików cookie takich jak promo_shown
. Jeśli czytelnik kliknie link
i chce, aby plik cookie był wysyłany, aby można było zastosować ich preferencje.
SameSite=Lax
umożliwia przeglądarce wysyłanie plików cookie z tymi najwyższego poziomu
elementów nawigacyjnych. Jeśli na przykład inna witryna odwołuje się do treści Twojej witryny, w polu
w tym przypadku, używając zdjęcia kota i podając link do artykułu
następujące:
<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>
Z plikiem cookie ustawionym na Lax
w ten sposób:
Set-Cookie: promo_shown=1; SameSite=Lax
Gdy przeglądarka poprosi o dostęp do amazing-cat.png
w przypadku bloga tej osoby,
witryna nie wysyła pliku cookie. Jeśli jednak czytelnik przestrzega
do cat.html
w Twojej witrynie, żądanie zawiera plik cookie.
Zalecamy korzystanie w ten sposób z SameSite
, ponieważ należy ustawiać pliki cookie, które będą miały wpływ na witrynę
wyświetlany w odpowiedzi na Lax
, a pliki cookie związane z działaniami użytkownika – Strict
.
Możesz też ustawić SameSite
na None
, aby wskazać, że plik cookie ma być utworzony
wysyłane we wszystkich kontekstach. Jeśli oferujesz usługę, z której korzystają inne witryny, np.
widżety, umieszczone treści, programy partnerskie, reklamy lub logowanie
w wielu witrynach, użyj parametru None
, aby mieć pewność, że Twój zamiar jest jasny.
Zmiany domyślnego zachowania bez zastosowania atrybutu SameSite
Obsługa przeglądarek
Atrybut SameSite
jest powszechnie obsługiwany, ale nie został powszechnie przyjęty.
W przeszłości ustawienia plików cookie bez modułu SameSite
domyślnie powodują wysyłanie tych plików
na wszystkich zagrożeniach, przez co użytkownicy są narażeni na ataki CSRF i niezamierzone
wycieku informacji. Aby zachęcić deweloperów do wyrażania swoich intencji
i zwiększyć bezpieczeństwo użytkowników, czyli propozycję IETF,
Stopniowo lepsze pliki cookie
wprowadza dwie kluczowe zmiany:
- Pliki cookie bez atrybutu
SameSite
są traktowane jakSameSite=Lax
. - Pliki cookie z atrybutem
SameSite=None
muszą też określićSecure
, co oznacza, że tego wymagają w bezpiecznym kontekście.
Obie te zmiany są zgodne wstecznie z przeglądarkami, które poprawnie
zastosowano poprzednią wersję atrybutu SameSite
, a także
przeglądarki, które nie obsługują starszych wersji SameSite
. Mają one na celu
zmniejszanie liczby programistów polegają na przeglądarkach domyślnego działania, tworząc plik cookie
i zamierzone użycie jest jednoznaczne. Klienci, którzy nie rozpoznają
SameSite=None
powinien go zignorować.
SameSite=Lax
domyślnie
Jeśli wyślesz plik cookie bez określenia jego atrybutu SameSite
, przeglądarka
traktuje ten plik cookie tak, jakby miał wartość SameSite=Lax
. Nadal polecamy
jawnie ustawiam SameSite=Lax
, aby zwiększyć spójność działań użytkowników
w różnych przeglądarkach.
Pole SameSite=None
musi być bezpieczne
Gdy tworzysz pliki cookie używane w różnych witrynach za pomocą SameSite=None
, musisz także je skonfigurować
Secure
, aby przeglądarka mogła je zaakceptować:
Set-Cookie: widget_session=abc123; SameSite=None; Secure
Możesz przetestować to zachowanie od Chrome 76, włączając
about://flags/#cookies-without-same-site-must-be-secure
i Firefox w wersji 69
przez ustawienie wartości network.cookie.sameSite.noneRequiresSecure
w
about:config
.
Zalecamy również jak najszybsze zaktualizowanie istniejących plików cookie do wersji Secure
.
Jeśli korzystasz z usług, które dostarczają w witrynie treści osób trzecich, upewnij się,
dostawcy usług aktualizuje jego pliki cookie i aktualizuje wszelkie fragmenty
w witrynie, aby upewnić się, że stosuje nowy sposób działania.
Przepisy na ciastka: SameSite
Więcej informacji o aktualizowaniu plików cookie pod kątem
zmian w interfejsie SameSite=None
oraz różnic w działaniu przeglądarek, zapoznaj się z opisem
kolejny artykuł: przepisy na ciasteczka w tej samej witrynie.
Dziękujemy za wkład i opinie od Lily Chen, Malte Ubl i Mike'a West, Rob Dodson, Tom Steiner i Vivek Sekhar.
Baner powitalny pliku cookie użytkownika Pille-Riin Priske włączono Odloty