Chrome, Firefox, Edge i inne firmy zmieniają swoje domyślne zachowanie zgodnie z propozycją IETF wzrostowo lepszej jakości plików cookie w taki sposób, aby:
- Pliki cookie bez atrybutu
SameSite
są traktowane jakoSameSite=Lax
, co oznacza, że działanie domyślne polega na ograniczaniu plików cookie tylko do własnych kontekstów. - Pliki cookie używane do użycia w innych witrynach muszą mieć wartość
SameSite=None; Secure
, aby umożliwić uwzględnienie w kontekście strony trzeciej.
Zaktualizuj atrybuty plików cookie innych firm, aby nie były blokowane w przyszłości.
Przypadki użycia plików cookie z innych witryn lub plików cookie innych firm
Istnieje wiele typowych przypadków użycia i wzorców, w przypadku których pliki cookie muszą być wysyłane w kontekście firmy zewnętrznej. Jeśli podasz jeden z tych przypadków użycia lub będziesz z niego korzystać, upewnij się, że albo Ty albo dostawca aktualizujesz pliki cookie, aby usługa działała prawidłowo.
Treści w: <iframe>
Treści z innej witryny wyświetlane w <iframe>
są w kontekście zewnętrznym. Standardowe przypadki użycia obejmują:
- Umieszczone treści udostępnione z innych witryn, takie jak filmy, mapy, przykłady kodu i posty społecznościowe.
- widżety z usług zewnętrznych, takich jak płatności, kalendarze, rezerwacje i rezerwacje;
- Widżety, np. przyciski społecznościowe czy usługi do zapobiegania oszustwom, które tworzą mniej oczywiste
<iframes>
.
Pliki cookie mogą być tu używane między innymi do utrzymywania stanu sesji, przechowywania ogólnych preferencji, generowania statystyk lub personalizowania treści dla użytkowników mających istniejące konta.
Sieć jest z natury kompozycyjna, więc <iframes>
służą też do umieszczania treści oglądanych na poziomie głównym lub własnym. Wszystkie pliki cookie używane przez witrynę w elemencie iframe są uznawane za pliki cookie innych firm. Jeśli tworzysz witryny, które chcesz umieścić w innych witrynach, i potrzebujesz plików cookie, aby działały, musisz się upewnić, że witryny są oznaczone do użytku w różnych witrynach lub że możesz bez problemów z nich korzystać.
„Niebezpieczne” żądania przesyłane między witrynami
Słowo „niebezpieczne” może wydawać się niepokojące, ale odnosi się do każdego żądania, które mogłoby spowodować zmianę stanu. W internecie są to głównie żądania POST. Pliki cookie oznaczone jako SameSite=Lax
są wysyłane na bezpieczne elementy nawigacyjne najwyższego poziomu, np. po kliknięciu linku prowadzącego do innej witryny. Jednak przesłanie żądania <form>
do innej witryny za pomocą metody POST nie zawiera plików cookie.
Ten wzorzec jest używany w przypadku witryn, które mogą przekierowywać użytkownika do usługi zdalnej w celu wykonania jakiejś operacji przed zwróceniem, na przykład do zewnętrznego dostawcy tożsamości. Zanim użytkownik opuści witrynę, ustawiany jest plik cookie zawierający token pojedynczego użycia z oczekiwaniem, że token ten może zostać sprawdzony w powracającym żądaniu w celu ograniczenia ataków CSRF. Jeśli zwracane żądanie jest wysyłane za pomocą metody POST, musisz oznaczyć pliki cookie jako SameSite=None; Secure
.
Zasoby zdalne
Każdy zasób zdalny na stronie, np. z tagów <img>
lub <script>
, może korzystać z plików cookie wysyłanych w żądaniu. Typowe zastosowania to m.in. piksele śledzące
i personalizacja treści.
Dotyczy to też żądań wysyłanych z JavaScriptu za pomocą fetch
lub XMLHttpRequest
. Jeśli funkcja fetch()
jest wywoływana za pomocą opcji credentials: 'include'
, żądania te prawdopodobnie będą zawierać pliki cookie.
W przypadku XMLHttpRequest
oczekiwane pliki cookie są zwykle oznaczone wartością withCredentials
właściwości true
. Aby pliki cookie były uwzględniane w żądaniach z innych witryn, muszą być odpowiednio oznaczone.
Treści w komponencie WebView
Komponent WebView w aplikacji na konkretnej platformie korzysta z przeglądarki. Deweloperzy muszą sprawdzić, czy ograniczenia lub problemy, które mają wpływ na ich aplikacje, mają zastosowanie również do komponentów WebView aplikacji.
Android pozwala też aplikacjom na danej platformie bezpośrednio ustawiać pliki cookie za pomocą interfejsu CookieManager API.
Podobnie jak w przypadku plików cookie ustawianych za pomocą nagłówków lub JavaScriptu, warto użyć parametru SameSite=None; Secure
, jeśli jest on przeznaczony do użytku w różnych witrynach.
Jak wdrożyć SameSite
już dziś
W zależności od potrzeb oznacz wszystkie pliki cookie, które są potrzebne tylko w kontekście własnych danych, jako SameSite=Lax
lub SameSite=Strict
. Jeśli nie oznaczysz tych plików cookie i będziesz obsługiwać je na podstawie domyślnego zachowania przeglądarki, mogą one działać niespójnie w różnych przeglądarkach i potencjalnie spowodować wyświetlanie ostrzeżeń w konsoli dla każdego z tych plików.
Set-Cookie: first_party_var=value; SameSite=Lax
Pamiętaj, aby oznaczyć wszystkie pliki cookie potrzebne w kontekście innej firmy jako SameSite=None; Secure
. Oba atrybuty są wymagane. Jeśli określisz właściwość None
bez Secure
, plik cookie zostanie odrzucony. Aby uwzględnić różnice w implementacjach przeglądarek, konieczne może być skorzystanie ze strategii łagodzących skutki opisanych w artykule Obsługa niezgodnych klientów.
Set-Cookie: third_party_var=value; SameSite=None; Secure
Obsługa niezgodnych klientów
Te zmiany dotyczące uwzględniania None
i aktualizacji domyślnego działania są wciąż stosunkowo nowe, dlatego różne przeglądarki obsługują je w różny sposób. Listę znanych problemów znajdziesz na stronie z aktualizacjami na chromium.org, ale może to nie być pełna lista.
Jednym z możliwych rozwiązań jest ustawienie każdego pliku cookie zarówno w nowym, jak i starym stylu:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
Przeglądarki implementujące nowsze działanie umieszczają w pliku cookie wartość SameSite
. Przeglądarki, które nie implementują nowego zachowania, ignorują tę wartość i tworzą plik cookie 3pcookie-legacy
. Podczas przetwarzania uwzględnionych plików cookie witryna powinna najpierw sprawdzić obecność nowego stylu pliku cookie, a gdy nie znajdzie nowego, może wrócić do starszego.
Z przykładu poniżej dowiesz się, jak to zrobić w środowisku Node.js przy użyciu platformy Express i jej oprogramowania pośredniczącego cookie-parser:
const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());
app.get('/set', (req, res) => {
// Set the new style cookie
res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
// And set the same value in the legacy cookie
res.cookie('3pcookie-legacy', 'value', { secure: true });
res.end();
});
app.get('/', (req, res) => {
let cookieVal = null;
if (req.cookies['3pcookie']) {
// check the new style cookie first
cookieVal = req.cookies['3pcookie'];
} else if (req.cookies['3pcookie-legacy']) {
// otherwise fall back to the legacy cookie
cookieVal = req.cookies['3pcookie-legacy'];
}
res.end();
});
app.listen(process.env.PORT);
Ta metoda wymaga wykonania dodatkowych czynności związanych z ustawieniem zbędnych plików cookie oraz wprowadzeniem zmian zarówno w przypadku konfigurowania, jak i odczytywania pliku cookie. Powinien on jednak obejmować wszystkie przeglądarki niezależnie od ich działania i utrzymywać działanie plików cookie innych firm.
Możesz też wykryć klienta za pomocą ciągu znaków klienta użytkownika podczas wysyłania nagłówka Set-Cookie
. Zapoznaj się z listą niezgodnych klientów i użyj odpowiedniej biblioteki wykrywania klientów użytkownika dla swojej platformy, np. biblioteki ua-parser-js w Node.js. Ta metoda wymaga wprowadzenia tylko jednej zmiany, ale przechwytywanie klientów użytkownika może nie wykryć niektórych użytkowników, u których występuje problem.
Obsługa SameSite=None
w językach, bibliotekach i platformach
Większość języków i bibliotek obsługuje atrybut SameSite
na potrzeby plików cookie. Ponieważ jednak właściwość SameSite=None
została dodana stosunkowo niedawno, może być teraz konieczne obejście pewnych standardowych działań.
Te zachowania są udokumentowane w repozytorium przykładów SameSite
na GitHubie.
Uzyskiwanie pomocy
Pliki cookie są używane wszędzie w internecie, a zespół programistów rzadko ma pełną wiedzę na temat tego, gdzie są umieszczane i jak z nich korzysta witryna, zwłaszcza w przypadku użycia w różnych witrynach. Jeśli napotkasz problem po raz pierwszy, więc skontaktuj się z nim po raz pierwszy:
- Zgłoś problem w repozytorium przykładów
SameSite
na GitHubie. - Zadaj pytanie w tagu „samesite” na stronie StackOverflow.
- W przypadku problemów z działaniem Chromium zgłoś błąd w narzędziu do śledzenia błędów Chromium.
- Obserwuj postępy w Chrome na stronie aktualizacji
SameSite
.