Przejdź do głównej zawartości

CHIPS w enterprise: partycjonowane ciasteczka i aplikacje w iframe

· 8 min aby przeczytać
Przemysław Majdak
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Blokady i partycjonowanie ciasteczek third-party paraliżują działanie krytycznych aplikacji biznesowych osadzonych w ramkach iframe — systemów płatności, czatów, widgetów CRM. Mechanizmem, który w 2026 roku rozwiązuje ten problem w sposób akceptowany przez wszystkie trzy silniki przeglądarek, jest CHIPS (Cookies Having Independent Partitioned State): podwójnie kluczowane kontenery pamięci, izolowane osobno dla każdej witryny najwyższego poziomu. Poniżej: dlaczego wygaszenie Privacy Sandbox go nie dotyczy, gdzie Safari nadal nie honoruje atrybutu Partitioned, i jak wygląda kompletna konfiguracja na przykładzie systemu contact center.

Ten tekst jest pogłębieniem jednego wątku z artykułu Ciasteczka w 2026: SameSite działa inaczej w każdej przeglądarce — skupionym na wdrożeniu CHIPS i na konkretnym studium przypadku.

Kryzys ciasteczek third-party a przetrwanie systemów wbudowanych​

Tradycyjne ciasteczka innych firm (third-party cookies) od lat stanowiły fundament stanowości aplikacji osadzanych na zewnętrznych domenach. Zapisywane w przeglądarce pod pojedynczym kluczem hosta (np. 3rd-party.example), były automatycznie wysyłane przy każdym żądaniu do tego hosta, bez względu na to, jaką stronę najwyższego poziomu odwiedzał użytkownik. Choć mechanizm ten umożliwiał realizację niezbędnych funkcji, takich jak utrzymanie sesji na wbudowanym komunikatorze, stał się także powszechnym narzędziem do śledzenia użytkowników w sieci.

W odpowiedzi na obawy dotyczące prywatności twórcy przeglądarek zaczęli wdrażać restrykcyjne reguły. Firefox wprowadził mechanizm podziału stanów (state partitioning, marketingowo: Total Cookie Protection) domyślnie dla wszystkich ciasteczek third-party, co potrafi generować nieoczekiwane błędy na serwerach nieprzygotowanych na taką architekturę. Safari podjęło próby partycjonowania na bazie heurystyki, jednak ostatecznie w ramach ITP zablokowało ciasteczka innych firm w kontekście cross-site.

Wątek Chrome'a jest w 2026 roku najczęściej opisywany nieaktualnie i wymaga uporządkowania. Obowiązują dwie daty:

  • 22 kwietnia 2025 — Google wycofuje się z planu usunięcia ciasteczek third-party z Chrome'a i rezygnuje z osobnego ekranu wyboru dla użytkownika.
  • 17 października 2025 — Google wygasza większość inicjatywy Privacy Sandbox. Odchodzą między innymi Topics, Protected Audience, Attribution Reporting, Private Aggregation, IP Protection oraz Related Website Sets (wraz z requestStorageAccessFor).

Kluczowe dla architekta jest to, co przetrwało: na liście technologii dalej wspieranych przez Chrome pozostały CHIPS, FedCM, Private State Tokens, Storage Access API oraz partycjonowanie magazynu i stanu sieciowego. CHIPS nie jest więc reliktem porzuconego programu — jest jednym z niewielu jego elementów, które weszły do trwałego utrzymania i zostały ustandaryzowane poza Google.

Praktyczny wniosek jest odwrotny do intuicji z lat 2020–2024. Presja na migrację nie zniknęła wraz z odwołaniem „cookiepocalypse" — przesunęła się z „ciasteczka third-party umrą" na „ciasteczka third-party są partycjonowane albo blokowane, w każdej przeglądarce według innej reguły". Kod, który zakłada niepartycjonowane ciasteczko w iframe, nadal jest kodem zepsutym.

Dzięki CHIPS ciasteczka mogą być zapisywane w izolowanych przedziałach (partitioned cookie jars) przypisanych do danej domeny nadrzędnej. Zamiast jednego klucza hosta przeglądarka stosuje podwójne kluczowanie (double-keying): klucz hosta oraz klucz partycji. Klucz partycji opiera się na schemacie (scheme) oraz domenie podlegającej rejestracji (registrable domain) witryny najwyższego poziomu. W efekcie ciasteczko ustawione przez widget osadzony na site-a.example nie zostanie wysłane, gdy ta sama usługa zostanie wywołana w ramce na site-b.example. Rozwiązuje to problem śledzenia, zachowując pełną stanowość w ramach jednej witryny nadrzędnej.

Partycjonowanie zachowuje przy tym działanie w obrębie subdomen witryny osadzającej: ten sam widget na shoppy.example, support.shoppy.example i checkout.shoppy.example operuje na jednym ciasteczku, bo klucz partycji (domena rejestrowalna) pozostaje ten sam.

Konstrukcja techniczna nagłówka i wymogi bezpieczeństwa​

Wdrożenie CHIPS wymaga modyfikacji nagłówków HTTP i wymuszenia rygorystycznych reguł bezpieczeństwa po stronie serwera aplikacji. Aby przeglądarka poprawnie zinterpretowała ciasteczko jako partycjonowane, serwer backendowy musi wysłać nagłówek Set-Cookie w postaci:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Wdrożenie standardu CHIPS wiąże się z bezwzględnymi warunkami technicznymi i architektonicznymi:

  • Wymóg Secure: atrybut Secure jest obowiązkowy. Każde ciasteczko posiadające flagę Partitioned, ale pozbawione flagi Secure (lub wysłane przez protokół inny niż HTTPS), zostanie przez przeglądarkę całkowicie zignorowane.
  • Wartość SameSite=None: Partitioned stosuje się łącznie z SameSite=None, nie zamiast niego. Partycjonowanie określa, do którego słoika trafi ciasteczko, a nie czy w ogóle zostanie wysłane w kontekście cross-site. Deklaracja daje przy okazji kompatybilność wsteczną: w przeglądarkach bez obsługi CHIPS ciasteczko zachowa się jak zwykłe third-party (o ile użytkownik ich nie blokuje).
  • Prefiks __Host-: rekomendowany, choć nieobowiązkowy. Wiąże ciasteczko z konkretną nazwą hosta zamiast z całą domeną rejestrowalną, wymuszając brak atrybutu Domain i Path=/. Od 2025 roku dostępny jest też ostrzejszy wariant __Host-Http-, który dodatkowo wymaga flagi HttpOnly i odcina odczyt z poziomu document.cookie (Chrome 140+, Firefox 143+; brak wsparcia w Safari — traktować jako wzmocnienie, nie jako mechanizm, na którym można polegać).
  • Limity pamięci: aby zapobiec zapychaniu pamięci klienta (state proliferation), przeglądarki nakładają limity. Chrome dopuszcza maksymalnie 180 ciasteczek na partycję, przy czym ich łączny rozmiar nie może przekroczyć 10 KB na osadzoną witrynę — limit liczony jest jako suma bajtów (oktetów) nazwy ciasteczka i jego wartości. Osobno obowiązuje ogólny limit 4096 oktetów na pojedyncze ciasteczko.
  • Czyszczenie danych (Clear-Site-Data): po odebraniu nagłówka Clear-Site-Data z dyrektywą "cookies" przeglądarka usuwa wyłącznie te ciasteczka partycjonowane, których klucz partycji odpowiada bieżącej domenie najwyższego poziomu. Zapobiega to nadużyciom polegającym na tworzeniu trwałych identyfikatorów śledzących między partycjami.

Kompatybilność przeglądarek i status standardu​

Od grudnia 2025 atrybut Partitioned ma status Baseline „newly available" — działa w aktualnych wersjach wszystkich głównych przeglądarek. Zamykającym elementem układanki było Safari 26.2; wcześniej WebKit miał tę funkcję krótko w 18.4 i wycofał ją w 18.5, co jest najczęstszym źródłem sprzecznych informacji w starszych zestawieniach.

Przeglądarka / platformaWsparcie Set-Cookie: Partitioned
Google Chromeod wersji 114
Microsoft Edgeod wersji 114
Mozilla Firefoxod wersji 141
Safari (macOS)od 26.2; wcześniej wyłącznie 18.4 (usunięte w 18.5)
Safari on iOSjak wyżej — od 26.2
Operaod wersji 100 (silnik Chromium 114)
Chrome Androidod wersji 114
Samsung Internet / WebViewwersje oparte na Chromium 114+

Status „newly available" ma konkretną konsekwencję operacyjną: nie jest to jeszcze wsparcie, na którym można polegać w całej bazie zainstalowanej. Urządzenia Apple utrzymujące się na Safari 18.5–26.1 nie zrealizują partycjonowania zgodnie z deklaracją. To argument nie przeciw wdrożeniu CHIPS, lecz za zaprojektowaniem ścieżki awaryjnej — degradacji do przepływu first-party albo do Storage Access API — zamiast zakładania, że deklaracja Partitioned wystarczy wszędzie.

Sama deklaracja jest natomiast bezpieczna do wprowadzenia od zaraz: w przeglądarce bez obsługi CHIPS atrybut jest ignorowany, a w Firefoksie i Safari partycjonowanie i tak zachodzi domyślnie. W najgorszym razie jest zbędny, nigdy szkodliwy.

Warto też odnotować zmianę po stronie alternatyw. Dokumentacja Google wciąż wskazuje jako rozwiązanie zastępcze Storage Access API wraz z Related Website Sets — ale RWS oraz requestStorageAccessFor znalazły się na liście technologii wygaszanych w październiku 2025. Realną alternatywą dla CHIPS pozostaje samo Storage Access API (z jawnym gestem użytkownika) oraz FedCM dla scenariuszy logowania federacyjnego.

Rekomendacje wdrożeniowe: case study Genesys Web Services​

Klasycznym przykładem infrastruktury enterprise, która ucierpiała z powodu blokad ciasteczek third-party, są systemy Genesys Web Services (GWS) 8.6. Platforma wykorzystuje osadzony serwer Jetty do serwowania aplikacji oraz szynę CometD (Ajax Push) do przesyłania powiadomień w czasie rzeczywistym. Jeśli agenci pracują w środowisku, gdzie aplikacja Workspace Web Edition (WWE) jest osadzona wewnątrz ramki iframe zewnętrznego systemu — Salesforce lub dedykowanego CRM — domyślne ciasteczka sesyjne przestają być przesyłane, a integracja przestaje się ładować.

Zapobiegają temu dwie zmiany w pliku application.yaml na każdym węźle Web Services.

Krok 1: aktywacja ciasteczek partycjonowanych (CHIPS)

Serwer Jetty trzeba jawnie poinstruować, żeby dokładał atrybut Partitioned do ciasteczek sesyjnych:

jetty:
  cookies:
    partitioned: true

Krok 2: konfiguracja bezpiecznego przesyłania (SameSite=None, Secure)

Reguły SameSite=None i Secure trzeba ustawić równolegle dla Jetty i dla CometD — pominięcie jednej z tych dwóch sekcji jest najczęstszym błędem wdrożeniowym, bo aplikacja ładuje się poprawnie, a przestaje działać kanał powiadomień:

jetty:
  cookies:
    secure: true
    sameSite: None
serverSettings:
  cometDSettings:
    cookieSecure: true
    cookieSameSite: None

Kluczowe ryzyka architektoniczne:

  • Wymóg HTTPS: konfiguracja zadziała wyłącznie, gdy parametr enableSsl jest ustawiony na true. Przy pracy po nieszyfrowanym HTTP ciasteczka oznaczone jako secure nie zostaną wysłane.
  • Pułapka Lax/Strict: ustawienie SameSite na Lax lub Strict pozwala co prawda pracować bez SSL (secure: false), ale całkowicie uniemożliwia osadzenie WWE w ramce iframe i niszczy integracje typu CRM Adapter. To konfiguracja poprawna wyłącznie dla wdrożeń, w których WWE działa jako aplikacja najwyższego poziomu.
  • Zasięg testów: skoro Safari partycjonuje niezależnie od deklaracji, a wersje 18.5–26.1 nie honorują atrybutu Partitioned, ścieżkę WWE w iframe trzeba przetestować osobno w WebKicie, a nie wyłącznie w Chromie.

Dla zespołów operacyjnych odpowiedzialnych za ciągłość działania contact center dostosowanie nagłówków sesyjnych Jetty i CometD do standardu CHIPS jest krytycznym punktem kontrolnym w planach migracji i aktualizacji infrastruktury — i to punktem, który nie zniknął wraz z odwołaniem przez Google planu usunięcia ciasteczek third-party.

Źródła​