A cookie-k típusai: teljes körű technikai útmutató

Nem minden cookie egyforma. A cookie típusa határozza meg, hogy meddig marad fenn, ki olvashatja, milyen biztonságosan halad az adatforgalomban, és — ami kulcsfontosságú — hogy szükséges-e hozzá a felhasználó hozzájárulása. E különbségek megértése elengedhetetlen mind a megfelelőség, mind a megvalósítás szempontjából.

Munkamenet-cookie-k vs. állandó cookie-k

A legalapvetőbb megkülönböztetés az, hogy meddig él egy cookie.

Munkamenet-cookie-k

A munkamenet-cookie csak a böngészési munkamenet idejére létezik. Nincs Expires vagy Max-Age attribútuma. Amikor a felhasználó bezárja a böngészőjét, a cookie törlődik.

Set-Cookie: cart_id=xyz789; Path=/; Secure; HttpOnly

A munkamenet-cookie-kat jellemzően a következőkre használják:

• A bejelentkezési állapot fenntartása egy látogatás során
• A bevásárlókosár tartalma
• CSRF elleni védelmi tokenek
• Többlépcsős űrlapadatok

Mivel a munkamenet-cookie-k nem maradnak fenn, adatvédelmi szempontból általában kevésbé zavaróak. Ugyanakkor továbbra is hozzájárulást igényelnek, ha nem feltétlenül szükségesek a felhasználó által kért szolgáltatáshoz.

Állandó cookie-k

Az állandó cookie-nak van kifejezett lejárati dátuma. Túléli a böngésző újraindítását, és a felhasználó eszközén marad, amíg le nem jár vagy manuálisan nem törlik.

Set-Cookie: preferences_lang=en; Path=/; Max-Age=31536000; Secure

Ez a cookie egy évig marad fenn (31 536 000 másodpercig). Gyakori felhasználási módjai:

• „Emlékezz rám” típusú bejelentkezési funkció
• Nyelvi és megjelenési beállítások
• Analitikai azonosítók (a Google Analytics cookie-jai akár 2 évig is fennmaradnak)
• Hirdetéskövetés (egyes hirdetési cookie-k 13 hónapig vagy tovább is fennmaradnak)

Az állandó cookie-k szigorúbb ellenőrzés alá esnek az adatvédelmi szabályozás keretében. A CNIL (Franciaország adatvédelmi hatósága) legfeljebb 13 hónapos cookie-élettartamot javasolt, és a hozzájárulást is legalább 13 havonta meg kell újítani.

Első féltől származó vs. harmadik féltől származó cookie-k

Ez a megkülönböztetés az adatvédelmi vita középpontjában áll, és közvetlenül befolyásolja a hozzájárulási követelményeket.

Első féltől származó cookie-k

Az első féltől származó cookie-t az a domain állítja be, amelyet a felhasználó ténylegesen meglátogat. Ha az example.com oldalt látogatja meg, akkor minden, az example.com által beállított cookie első féltől származik.

Az első féltől származó cookie-kat az alapvető weboldal-funkciókhoz használják: munkamenetek, beállítások, valamint a weboldal üzemeltetője által saját maga futtatott analitika. Ezeket csak az a domain olvashatja, amely beállította őket.

Példa: Felkeresi a shop.example.com oldalt. A szerver beállít egy session_id nevű cookie-t. Ez a cookie kizárólag a shop.example.com és aldomainjei felé kerül elküldésre. Más weboldal nem férhet hozzá.

Harmadik féltől származó cookie-k

A harmadik féltől származó cookie-t nem az a domain állítja be, amelyet a felhasználó látogat. Amikor az example.com betölt egy hirdetési szkriptet az ads.tracker.com oldalról, és az a szkript beállít egy cookie-t a tracker.com domain alatt, az harmadik féltől származó cookie.

Így működik a webhelyek közötti követés. A tracker.com cookie minden, a tracker.com felé irányuló kéréssel elküldésre kerül, függetlenül attól, hogy melyik weboldal váltotta ki a kérést. Ha a tracker.com szkriptjei 10 000 weboldalba vannak beágyazva, mind a 10 000 oldalon nyomon követhetik ugyanazt a felhasználót.

A harmadik féltől származó cookie-k mind a szabályozói fellépések, mind a böngészőszintű korlátozások elsődleges célpontjai:

• A Safari 2020 óta alapértelmezetten blokkolja a harmadik féltől származó cookie-kat (ITP)
• A Firefox alapértelmezetten blokkolja az ismert harmadik féltől származó nyomkövetőket (ETP)
• A Chrome a Privacy Sandbox kezdeményezéssel fokozatosan felhagy a harmadik féltől származó cookie-kkal
• A szabályozói fellépések elsöprő többsége a harmadik féltől származó nyomkövető cookie-kat célozza

Biztonságos (Secure) cookie-k

A Secure attribútummal rendelkező cookie csak HTTPS-kapcsolaton keresztül kerül elküldésre. Soha nem továbbítódik titkosítatlan HTTP-n.

Set-Cookie: auth_token=secret123; Secure

Ez megakadályozza, hogy egy man-in-the-middle támadó lehallgassa a cookie-t egy nem biztonságos kapcsolaton. Minden érzékeny információt tartalmazó cookie-t — munkamenet-azonosítókat, hitelesítési tokeneket, személyes adatokat — mindig Secure jelöléssel kell ellátni.

Megfelelőségi szempontból az érzékeny cookie-knál a Secure jelző elmulasztása a megfelelő technikai intézkedések megvalósításának elmulasztásaként értékelhető a GDPR 32. cikke (az adatkezelés biztonsága) alapján.

HttpOnly cookie-k

A HttpOnly attribútummal rendelkező cookie-hoz a JavaScript nem férhet hozzá a document.cookie révén. Csak a szerver felé irányuló HTTP-kérésekkel kerül elküldésre.

Set-Cookie: session_id=abc123; HttpOnly

Ez kritikus biztonsági intézkedés. A cross-site scripting (XSS) támadások gyakran úgy próbálnak cookie-kat ellopni, hogy olyan JavaScript-kódot juttatnak be, amely beolvassa a document.cookie tartalmát. A HttpOnly jelző teljesen kizárja ezt a támadási vektort.

A munkamenet- és hitelesítési cookie-knak szinte mindig HttpOnly-nak kell lenniük. Azok a cookie-k, amelyeket a kliensoldali JavaScriptnek olvasnia kell (például a felhasználói felületet befolyásoló beállítási cookie-k), nem lehetnek HttpOnly.

SameSite cookie-k

A SameSite attribútum azt szabályozza, hogy egy cookie elküldésre kerül-e a webhelyek közötti kérésekkel. A cross-site request forgery (CSRF) támadások mérséklésére vezették be, és arra, hogy a webhelyek nagyobb kontrollt kapjanak a webhelyek közötti cookie-viselkedés felett.

SameSite=Strict

A cookie csak azonos webhelyről származó kérésekkel kerül elküldésre. Ha egy felhasználó az other.com oldalon egy olyan linkre kattint, amely a your-site.com oldalra vezet, a cookie nem kerül elküldésre ezzel a kezdeti kéréssel.

Ez a legbiztonságosabb beállítás, de megzavarhatja a legitim működést. Ha például a felhasználó egy e-mailből kattint egy linkre a webhelyére, a munkamenet-cookie-ja nem kerülne elküldésre, így kijelentkezettnek tűnne.

SameSite=Lax

A cookie elküldésre kerül a legfelső szintű navigációknál (linkre kattintás), de nem a webhelyek közötti alkéréseknél (képek, keretek betöltése vagy más webhelyről indított AJAX-kérések). Ez az alapértelmezett érték a modern böngészőkben, ha nincs megadva SameSite attribútum.

A Lax ésszerű egyensúlyt biztosít a biztonság és a használhatóság között. Megakadályozza, hogy harmadik féltől származó webhelyek hitelesített műveleteket váltsanak ki az Ön oldalán, miközben a normál linknavigáció továbbra is működik.

SameSite=None

A cookie minden kéréssel elküldésre kerül, beleértve a webhelyek közötti kéréseket is. Erre a harmadik féltől származó cookie-k működéséhez van szükség. A SameSite=None értékkel beállított cookie-nak a Secure attribútummal is rendelkeznie kell.

Set-Cookie: tracking_id=xyz; SameSite=None; Secure

Minden olyan cookie-nak, amelynek webhelyek közötti környezetben kell működnie (beágyazott widgetek, harmadik féltől származó hitelesítés, webhelyek közötti követés), a SameSite=None értéket kell használnia. Ez egyre inkább releváns, ahogy a böngészők szigorítják alapértelmezett cookie-szabályaikat.

Zombi cookie-k és szuper-cookie-k

Ezeket érdemes megemlíteni, mert az adatvédelmi kontrollok megkerülésére tett kísérleteket képviselik:

• A zombi cookie-k olyan cookie-k, amelyek törlésük után újralétrejönnek. Jellemzően úgy működnek, hogy ugyanazt az azonosítót több tárolási mechanizmusban is eltárolják (cookie-k, localStorage, IndexedDB, Flash LSO-k), és amelyik túléli, azt használják fel a többi újragenerálásához. Ezt a gyakorlatot széles körben megtévesztőnek tartják, és fellépések tárgyát képezte.
• A szuper-cookie-k olyan nyomkövetési mechanizmusok, amelyek a normál cookie-k alatti szinten működnek — például internetszolgáltatói szintű fejlécbeszúrás (a Verizon UIDH-ja) vagy HSTS-alapú ujjlenyomatvétel. A felhasználók számára rendkívül nehéz ezeket kontrollálni vagy törölni.

Mind a zombi cookie-k, mind a szuper-cookie-k egyértelműen összeegyeztethetetlenek a GDPR és az ePrivacy követelményeivel. Használatuk sértené az átláthatóság, a jogszerűség és az adattakarékosság elveit.

Összehasonlító táblázat

Típus	Élettartam	Hatókör	Általában szükséges hozzájárulás?	Fő felhasználási esetek
Munkamenet	Csak a böngészési munkamenet	Első fél	Csak ha nem elengedhetetlen	Bejelentkezési állapot, kosár, CSRF-tokenek
Állandó (első fél)	Napoktól évekig	Első fél	Általában igen	Beállítások, analitika, „emlékezz rám”
Állandó (harmadik fél)	Napoktól évekig	Webhelyek közötti	Szinte mindig igen	Hirdetés, retargeting, közösségi widgetek
Secure	Változó	Csak HTTPS	Céltól függ	Bármely érzékeny cookie
HttpOnly	Változó	Csak szerveroldali	Céltól függ	Munkamenet-azonosítók, hitelesítési tokenek
SameSite=Strict	Változó	Csak azonos webhely	Céltól függ	CSRF-érzékeny műveletek
SameSite=Lax	Változó	Azonos webhely + legfelső szintű navigáció	Céltól függ	Általános munkamenet-kezelés
SameSite=None	Változó	Minden környezet (Secure szükséges)	Szinte mindig igen	Harmadik féltől származó beágyazások, webhelyek közötti hitelesítés

Mit jelent ez a megfelelőség szempontjából

A cookie típusa közvetlenül befolyásolja a megfelelőségi kötelezettségeit:

1. A feltétlenül szükséges első féltől származó munkamenet-cookie-k (bejelentkezési munkamenetek, bevásárlókosarak, CSRF-tokenek) mentesülnek a hozzájárulási követelmények alól az ePrivacy 5. cikk (3) bekezdése alapján.
2. Az analitikai, beállítási vagy funkcionális célú első féltől származó állandó cookie-k általában hozzájárulást igényelnek — bár egyes adatvédelmi hatóságok bizonyos feltételek mellett korlátozott kivételeket engedélyeznek az első féltől származó analitikára.
3. Bármilyen harmadik féltől származó cookie szinte mindig kifejezett, előzetes hozzájárulást igényel. Nagyon kevés a legitim kivétel.
4. A biztonsági attribútumok (Secure, HttpOnly, SameSite) nem változtatnak a hozzájárulási követelményeken, de használatuk jó biztonsági gyakorlatot mutat — ami önmagában is GDPR-követelmény.

Annak pontos ismerete, hogy weboldala mely cookie-kat állítja be — és mindegyik milyen típusú —, minden megfelelőségi program alapja. A Passiro szkennere automatikusan azonosítja és osztályozza a weboldalán található összes cookie-t, beleértve a beágyazott szkriptek által beállított harmadik féltől származó cookie-kat is, amelyekről talán nem is tud.

Most, hogy megértettük a típusokat, nézzük meg, hogyan szerveződnek a cookie-k hozzájárulási kategóriákba — ez az osztályozási rendszer határozza meg, hogyan jelennek meg a cookie-bannerében.