Dlaczego nagłówek Set-Cookie został pomyślnie ustawiony, ale przeglądarka nie zapisała mojego pliku Cookie?
Jest to najczęstszy problem: przeglądarka nie zgłasza aktywnie błędu, tylko po cichu odrzuca pliki Cookie niezgodne z wymaganiami. Typowe przyczyny to: SameSite=None bez Secure, plik Secure Cookie ustawiany ze strony HTTP (z wyjątkiem localhost), prefiksy __Host-/__Secure- nie spełniają ograniczeń, niezgodność Domain/Path, przekroczony limit 4 KB, Max-Age wynosi 0 lub jest ujemny. Zaleca się najpierw wkleić Set-Cookie do tego narzędzia, aby zlokalizować konkretną przyczynę za pomocą odznak ostrzeżeń, a następnie otworzyć Chrome DevTools → Application → Cookies, sprawdzić pod odpowiednią domeną, czy jest żółty trójkąt ostrzeżenia — po najechaniu kursorem zobaczysz konkretną przyczynę odrzucenia.
Jaka jest dokładna różnica między Strict, Lax i None w SameSite? Kiedy używać której wartości?
Strict całkowicie zabrania wysyłania cross-site, jest najbezpieczniejszy, ale użytkownik będzie wyglądał na wylogowanego po kliknięciu linków z innych witryn, odpowiedni dla plików Cookie wrażliwych operacji, takich jak płatności/zmiana hasła. Lax to wartość domyślna w Chrome 80+, zezwala na wysyłanie podczas nawigacji GET najwyższego poziomu (kliknięcie linku z innej witryny powracającego do Twojej witryny), ale nie jest wysyłany w podzasobach, takich jak iframe/img/script/XHR/formularze POST, i jest zalecaną wartością dla większości scenariuszy. None zezwala na wysyłanie we wszystkich scenariuszach cross-site (używany do jednokrotnego logowania SSO, osadzeń firm trzecich w iframe, wywołań API cross-site), ale wymaga jednoczesnego ustawienia Secure, w przeciwnym razie przeglądarka odrzuca bezpośrednio.
Dlaczego SameSite=None musi być połączony z Secure?
Jest to reguła wymuszona przez Chrome począwszy od wersji 80 (luty 2020), za którą poszły Firefox, Edge i Safari. Ponieważ SameSite=None jawnie zezwala na wysyłanie cross-site plików Cookie, atakujący mają łatwiejsze przeprowadzanie CSRF lub podsłuchiwania w scenariuszach cross-site, konieczne jest połączenie z Secure (szyfrowana transmisja HTTPS) w celu zmniejszenia ryzyk. Jeśli Twój plik Cookie SameSite=None jest ustawiany przez HTTP, przeglądarka go odrzuci bez zapisywania. To narzędzie wykrywa kombinację SameSite=None bez Secure i oznacza ją czerwonym ostrzeżeniem.
Czego używać: Max-Age czy Expires? Jaka jest różnica?
Preferuj Max-Age. Max-Age to czas względny (wygasa po N sekundach), nie jest zależny od zegara klienta, przeglądarka rozpoczyna odliczanie natychmiast po otrzymaniu; Expires to bezwzględny punkt w czasie, zależny od lokalnego czasu komputera użytkownika (jeśli użytkownik przestawi zegar na 1970, plik Cookie natychmiast wygaśnie). Gdy oba są obecne, Max-Age ma wyższy priorytet (jasno określone w RFC 6265). Jeśli żaden nie jest ustawiony, plik Cookie staje się «plikiem Cookie sesji», który wygasa po zamknięciu przeglądarki. To narzędzie podaje wskazówkę, gdy Expires jest ustawiony, a Max-Age nie, zalecając dodanie Max-Age. Uwaga: jednostka Max-Age to sekundy, a nie milisekundy.
Jaka jest różnica między Path=/ a nieustawieniem Path?
Path określa, w jakich ścieżkach URL przeglądarka będzie wysyłać ten plik Cookie w żądaniach. Gdy Path nie jest ustawiona, przeglądarka domyślnie używa «ścieżki adresu URL odpowiedzi bez ostatniego segmentu». Na przykład podczas ustawiania pliku Cookie z /api/user/login domyślna Path to /api/user/, więc żądania w ścieżce / i /order/ nie będą wysyłać tego pliku Cookie. Jawne ustawienie Path=/ sprawia, że plik Cookie obowiązuje dla całej witryny. Uwaga: dopasowywanie Path to dopasowywanie prefiksu — Path=/api będzie również pasować do /api/, /api/user, /api/v2/abc itp. Pliki Cookie z prefiksem __Host- bezwzględnie wymagają Path=/.
Jaka jest różnica między Domain z kropką na początku (np. .example.com) a bez kropki?
W nowoczesnych przeglądarkach (aktualne wersje Chrome, Firefox, Edge, Safari) obie opcje są już równoważne: obie sprawiają, że plik Cookie obowiązuje dla example.com i wszystkich jego poddomen (a.example.com, b.c.example.com). Kropka na początku była starą składnią z czasów RFC 2109 — RFC 6265 już określa, że początkowa kropka jest ignorowana. Jednak dla czytelności zaleca się pisanie bez kropki. To narzędzie podaje wskazówkę, gdy Domain ma początkową kropkę (nie jest to błąd, ale przestarzała składnia). Uwaga: gdy Domain nie jest ustawiony, plik Cookie obowiązuje tylko dla bieżącego hosta (poddomeny go nie otrzymują), po ustawieniu Domain zaczyna obowiązywać dla poddomen.
Co to są prefiksy __Host- i __Secure-? Czy można pracować bez prefiksów?
Są to prefiksy bezpieczeństwa nazw plików Cookie wprowadzone w RFC 6265bis w celu narzucenia surowych ograniczeń dla plików Cookie o wysokim bezpieczeństwie: gdy przeglądarka widzi, że nazwa pliku Cookie zaczyna się od __Host-, bezwzględnie wymaga ustawienia Secure, Path=/ i braku atrybutu Domain — jeśli jakikolwiek warunek nie jest spełniony, bezpośrednio odrzuca zapisanie; prefiks __Secure- wymaga ustawienia Secure, pozostałe atrybuty mogą być skonfigurowane. Praca bez prefiksów również jest możliwa (większość plików Cookie nie używa prefiksów), ale dla plików Cookie o wysokim bezpieczeństwie, takich jak identyfikatory sesji, tokeny autoryzacyjne, zdecydowanie zaleca się używanie prefiksu __Host-, ponieważ zapobiega atakom wstrzykiwania plików Cookie na poziomie poddomen/ścieżek. To narzędzie automatycznie sprawdza zgodność obu prefiksów.
Czy plik Cookie z HttpOnly jest naprawdę bezpieczny? Czy chroni przed XSS i CSRF?
HttpOnly uniemożliwia JavaScript odczytywanie wartości plików Cookie przez document.cookie, będąc ważną linią obrony do <strong>ograniczania kradzieży sesji przez XSS</strong>, ale nie jest cudownym lekarstwem: atakujący XSS nadal mogą wykonywać żądania w przeglądarce użytkownika (żądania automatycznie niosą plik Cookie) w celu wykonania akcji (to jest zakres CSRF); HttpOnly również nie broni przed atakami CSRF (wymagany jest SameSite lub CSRF Token). Tylko jednoczesne użycie trójki HttpOnly+Secure+SameSite=Lax/Strict zapewnia podstawowy poziom bezpieczeństwa. Wrażliwe pliki Cookie (session, JWT, access_token) muszą mieć HttpOnly, nie dawaj dostępu do nich JS front-endu bez konieczności. To narzędzie oznacza ostrzeżeniem pliki Cookie bez HttpOnly.
Co to jest plik Cookie Partitioned (CHIPS)? Kiedy należy go używać?
Partitioned to nowy atrybut wprowadzony przez Chrome w odpowiedzi na wycofywanie plików Cookie firm trzecich, o pełnej nazwie Cookies Having Independent Partitioned State (CHIPS). Tradycyjne pliki Cookie firm trzecich (np. te z reklam/usług osadzonych ustawiane w wielu witrynach) są współdzielone globalnie i mogą być używane do śledzenia użytkowników cross-site. Dzięki Partitioned przeglądarka przechowuje plik Cookie firmy trzeciej oddzielnie dla każdej witryny najwyższego poziomu: plik Cookie firmy trzeciej, który użytkownik widzi w Witrynie A, jest całkowicie niezależny od tego widzianego w Witrynie B i nie może współdzielić tożsamości cross-site. Scenariusze użycia: osadzone komponenty wideo/map/płatności, wtyczki czatu firm trzecich, SSO cross-site osadzone w iframe. Używanie Partitioned wymaga jednoczesnego ustawienia Secure, zalecane z prefiksem __Host-.
Ile maksymalnie może przechowywać jeden plik Cookie? Ile plików Cookie może być na jedną domenę?
Według RFC 6265 przeglądarki obsługują co najmniej 4096 bajtów na plik Cookie (w tym nazwę, wartość i atrybuty), a główne przeglądarki (Chrome/Firefox/Safari/Edge) przestrzegają tego limitu — zawartość przekraczająca limit jest obcinana lub odrzucana po cichu. Limity liczby różnią się w zależności od przeglądarki: Chrome ma około 180 na domenę, Firefox około 150, Safari około 600 (i podlega wpływowi 7-dniowej polityki czyszczenia ITP); po przekroczeniu przeglądarka usuwa najstarsze pliki Cookie zgodnie z polityką LRU. Zaleca się, aby pliki Cookie przechowywały tylko identyfikatory sesji, nie umieszczaj w plikach Cookie dużych ilości danych biznesowych (dane biznesowe umieszczaj w localStorage lub sesji serwerowej).
Czy narzędzie obsługuje kopiowanie Set-Cookie bezpośrednio z Chrome DevTools do analizy? Czy muszę ręcznie usuwać prefiks?
Pełna obsługa, bez konieczności ręcznego przetwarzania. Możesz kliknąć docelowe żądanie w panelu Network Chrome DevTools, kliknąć prawym przyciskiem myszy wartość Set-Cookie w obszarze Response Headers, aby bezpośrednio skopiować (dla wielu wierszy Ctrl/⌘+kliknięcie do wyboru wielokrotnego lub skopiuj cały blok) i wkleić do obszaru wprowadzania tego narzędzia. Narzędzie automatycznie usuwa prefiks Set-Cookie: z początku każdego wiersza (niewrażliwe na wielkość liter), automatycznie przetwarza białe znaki na początku/końcu wierszy, poprawnie obsługuje znaki specjalne, takie jak przecinki i średniki w datach Expires, a także poprawnie przetwarza wartości plików Cookie w podwójnych cudzysłowach.
Dlaczego chińskie lub specjalne znaki w wartościach plików Cookie przybierają postać %XX?
RFC 6265 wymaga, aby wartości plików Cookie używały tylko bezpiecznego podzbioru zestawu znaków ASCII i nie mogą bezpośrednio zawierać znaków nie-ASCII, spacji, przecinków, średników itp. Wiele frameworków serwerowych podczas ustawiania plików Cookie automatycznie wykonuje kodowanie URL (encodeURIComponent/Percent-encoding) znaków nie-ASCII. Przeglądarki również zachowują zakodowaną formę podczas zwracania. Gdy to narzędzie wykryje, że wartość zawiera kodowanie %XX, automatycznie wyświetla oryginalny tekst zdekodowany przez decodeURIComponent obok surowej wartości z zieloną strzałką, aby ułatwić przeglądanie rzeczywistej zawartości.
Jaka jest różnica między Set-Cookie a nagłówkiem żądania Cookie?
Są to nagłówki o zupełnie innych kierunkach: Set-Cookie to nagłówek odpowiedzi (serwer→przeglądarka), pojawia się tylko w odpowiedziach, może wystąpić wielokrotnie, za każdym razem ustawiając jeden plik Cookie z pełnymi atrybutami (Secure/HttpOnly/Path/Domain itp.); Cookie to nagłówek żądania (przeglądarka→serwer), pojawia się tylko raz na żądanie, zawierając wszystkie pary name=value plików Cookie pasujących do bieżącego zakresu w płaskiej formie (name1=v1; name2=v2), bez żadnych informacji o atrybutach. Oznacza to, że serwer nie może wiedzieć z żądania, czy dany plik Cookie ma ustawiony HttpOnly lub Secure — informacje o atrybutach są przechowywane przez przeglądarkę tylko podczas lokalnego przechowywania. Do analizy nagłówka Cookie w żądaniach użyj towarzyszącego <a href='/network/http-cookie-parser/'>Parsera nagłówka żądania Cookie</a>.
Dlaczego w Safari moje pliki Cookie znikają po kilku dniach?
Dzieje się tak za sprawą mechanizmu Inteligentnej Ochrony przed Śledzeniem Safari (ITP: Intelligent Tracking Prevention). Począwszy od ITP 2.1, jeśli użytkownik nie wchodzi w bezpośrednią interakcję z domeną przez 7 dni (to znaczy nie odwiedza bezpośrednio witryny tej domeny), Safari czyści wszystkie pliki Cookie i dane witryn pod tą domeną, niezależnie od tego, jak długi Max-Age/Expires są ustawione. Wpływa to najbardziej na osadzone usługi firm trzecich, podczas gdy pliki Cookie witryny głównej nie są dotknięte, o ile użytkownik nadal ją odwiedza. Ponadto ograniczenia Safari dotyczące plików Cookie firm trzecich są bardziej rygorystyczne niż w Chrome. Rozwiązania obejmują: używanie atrybutu Partitioned, żądanie uprawnień przez Storage Access API lub odnawianie pliku Cookie, gdy użytkownik odwiedza witrynę główną. Sekcja rozwiązywania problemów tego narzędzia zawiera bardziej szczegółowe wskazówki dotyczące debugowania w Safari.
Czy narzędzie obsługuje wsadową analizę wielu Set-Cookie? Czy zawartość pliku Cookie jest wysyłana na serwery?
Obsługuje analizę wsadową. Obszar wprowadzania obsługuje wklejanie dowolnej liczby wierszy Set-Cookie (np. wklejenie od razu całego bloku nagłówków odpowiedzi), każdy Set-Cookie jest analizowany z niezależną numeracją, za pomocą wielu kart atrybutów wyświetlających oddzielnie atrybuty i ostrzeżenia. Cały proces analizy jest wykonywany całkowicie lokalnie w Twojej przeglądarce (czyste przetwarzanie JavaScript po stronie front-endu), zawartość pliku Cookie nie jest wysyłana na żadne serwery, nie są wykonywane żadne żądania sieciowe — wrażliwe informacje, takie jak Session/Token, które wklejasz, nie opuszczają Twojego komputera, możesz używać z spokojem.
