Soorten cookies: een complete technische gids

Niet alle cookies zijn hetzelfde. Het type cookie bepaalt hoe lang het blijft bestaan, wie het kan lezen, hoe veilig het wordt verzonden en — cruciaal — of er toestemming van de gebruiker voor nodig is. Deze verschillen begrijpen is essentieel voor zowel compliance als implementatie.

Sessiecookies versus permanente cookies

Het meest fundamentele onderscheid is hoe lang een cookie meegaat.

Sessiecookies

Een sessiecookie bestaat alleen zolang een browsersessie duurt. Het heeft geen Expires- of Max-Age-attribuut. Zodra de gebruiker zijn browser sluit, wordt het cookie verwijderd.

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

Sessiecookies worden doorgaans gebruikt voor:

• Het behouden van de inlogstatus tijdens een bezoek
• De inhoud van het winkelmandje
• CSRF-beveiligingstokens
• Gegevens van formulieren met meerdere stappen

Omdat sessiecookies niet blijven bestaan, zijn ze vanuit privacyoogpunt over het algemeen minder ingrijpend. Toch is er toestemming voor nodig als ze niet strikt noodzakelijk zijn voor de dienst die de gebruiker heeft aangevraagd.

Permanente cookies

Een permanent cookie heeft een expliciete vervaldatum. Het overleeft het opnieuw opstarten van de browser en blijft op het apparaat van de gebruiker staan totdat het verloopt of handmatig wordt verwijderd.

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

Dit cookie blijft één jaar bestaan (31.536.000 seconden). Veelvoorkomende toepassingen zijn onder andere:

• Functionaliteit om je aanmelding te onthouden
• Taal- en thema-voorkeuren
• Analytics-identifiers (Google Analytics-cookies blijven tot 2 jaar bestaan)
• Advertentietracking (sommige advertentiecookies blijven 13 maanden of langer bestaan)

Permanente cookies worden onder privacyregelgeving strenger beoordeeld. De CNIL (de Franse toezichthouder voor gegevensbescherming) heeft een maximale levensduur van 13 maanden aanbevolen, en toestemming moet eveneens minstens elke 13 maanden worden vernieuwd.

First-party- versus third-party-cookies

Dit onderscheid staat centraal in het privacydebat en heeft directe gevolgen voor de toestemmingsvereisten.

First-party-cookies

Een first-party-cookie wordt geplaatst door het domein dat de gebruiker daadwerkelijk bezoekt. Als je example.com bezoekt, is elk cookie dat door example.com wordt geplaatst een first-party-cookie.

First-party-cookies worden gebruikt voor de kernfunctionaliteit van een website: sessies, voorkeuren en analytics die de website-exploitant zelf uitvoert. Ze kunnen alleen worden gelezen door het domein dat ze heeft geplaatst.

Voorbeeld: je bezoekt shop.example.com. De server plaatst een cookie met de naam session_id. Dit cookie wordt alleen verzonden naar shop.example.com en de bijbehorende subdomeinen. Geen enkele andere website heeft er toegang toe.

Third-party-cookies

Een third-party-cookie wordt geplaatst door een ander domein dan het domein dat de gebruiker bezoekt. Wanneer example.com een advertentiescript laadt van ads.tracker.com en dat script een cookie plaatst onder het domein tracker.com, is dat een third-party-cookie.

Zo werkt tracking over verschillende websites heen. Het tracker.com-cookie wordt bij elk verzoek naar tracker.com meegestuurd, ongeacht welke website het verzoek heeft geactiveerd. Als de scripts van tracker.com op 10.000 websites zijn ingebed, kunnen ze dezelfde gebruiker over al die 10.000 sites volgen.

Third-party-cookies zijn het belangrijkste doelwit van zowel handhaving door toezichthouders als beperkingen op browserniveau:

• Safari blokkeert third-party-cookies sinds 2020 standaard (ITP)
• Firefox blokkeert bekende third-party-trackers standaard (ETP)
• Chrome stapt geleidelijk af van third-party-cookies met zijn Privacy Sandbox-initiatief
• Handhavingsacties van toezichthouders richten zich overweldigend op third-party-trackingcookies

Secure-cookies

Een cookie met het Secure-attribuut wordt alleen via HTTPS-verbindingen verzonden. Het wordt nooit over een onversleutelde HTTP-verbinding verstuurd.

Set-Cookie: auth_token=secret123; Secure

Dit voorkomt dat een man-in-the-middle-aanvaller het cookie onderschept op een onbeveiligde verbinding. Elk cookie dat gevoelige informatie bevat — sessie-identifiers, authenticatietokens, persoonsgegevens — moet altijd als Secure worden gemarkeerd.

Vanuit complianceoogpunt zou het niet gebruiken van de Secure-vlag bij gevoelige cookies kunnen worden gezien als het niet nemen van passende technische maatregelen onder artikel 32 AVG (beveiliging van de verwerking).

HttpOnly-cookies

Een cookie met het HttpOnly-attribuut kan niet door JavaScript worden benaderd via document.cookie. Het wordt alleen meegestuurd met HTTP-verzoeken naar de server.

Set-Cookie: session_id=abc123; HttpOnly

Dit is een cruciale beveiligingsmaatregel. Cross-site scripting-aanvallen (XSS) proberen vaak cookies te stelen door JavaScript te injecteren dat document.cookie uitleest. De HttpOnly-vlag blokkeert deze aanvalsroute volledig.

Sessiecookies en authenticatiecookies moeten vrijwel altijd HttpOnly zijn. Cookies die door client-side JavaScript moeten worden gelezen (zoals voorkeurscookies die de UI beïnvloeden) kunnen niet HttpOnly zijn.

SameSite-cookies

Het SameSite-attribuut bepaalt of een cookie wordt meegestuurd met cross-site-verzoeken. Het werd geïntroduceerd om cross-site request forgery-aanvallen (CSRF) te beperken en om sites meer controle te geven over cross-site-cookiegedrag.

SameSite=Strict

Het cookie wordt alleen meegestuurd met verzoeken die van dezelfde site afkomstig zijn. Als een gebruiker op other.com op een link klikt die naar your-site.com gaat, wordt het cookie niet meegestuurd met dat eerste verzoek.

Dit is de veiligste instelling, maar kan legitieme functionaliteit verstoren. Als een gebruiker bijvoorbeeld vanuit een e-mail op een link naar je site klikt, wordt zijn sessiecookie niet meegestuurd en lijkt hij uitgelogd te zijn.

SameSite=Lax

Het cookie wordt meegestuurd bij navigaties op het hoogste niveau (het klikken op een link), maar niet bij cross-site-subverzoeken (het laden van afbeeldingen, frames of het uitvoeren van AJAX-verzoeken vanaf een andere site). Dit is de standaardinstelling in moderne browsers als er geen SameSite-attribuut is opgegeven.

Lax biedt een redelijke balans tussen beveiliging en gebruiksgemak. Het voorkomt dat externe sites geauthenticeerde acties op jouw site triggeren, terwijl normale linknavigatie gewoon blijft werken.

SameSite=None

Het cookie wordt met alle verzoeken meegestuurd, inclusief cross-site-verzoeken. Dit is vereist om third-party-cookies te laten werken. Een cookie dat met SameSite=None is ingesteld, moet ook het Secure-attribuut hebben.

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

Elk cookie dat in een cross-site-context moet werken (ingebedde widgets, third-party-authenticatie, cross-site-tracking) moet SameSite=None gebruiken. Dit wordt steeds relevanter naarmate browsers hun standaard-cookiebeleid aanscherpen.

Zombiecookies en supercookies

Deze zijn het vermelden waard omdat ze pogingen vertegenwoordigen om privacycontroles te omzeilen:

• Zombiecookies zijn cookies die zichzelf opnieuw aanmaken nadat ze zijn verwijderd. Ze werken doorgaans door dezelfde identifier in meerdere opslagmechanismen op te slaan (cookies, localStorage, IndexedDB, Flash LSO's) en gebruiken vervolgens degene die overleeft om de andere te herstellen. Deze praktijk wordt algemeen als misleidend beschouwd en heeft geleid tot handhavingsacties.
• Supercookies zijn trackingmechanismen die opereren op een niveau onder gewone cookies — zoals headerinjectie op ISP-niveau (Verizons UIDH) of op HSTS gebaseerde fingerprinting. Ze zijn voor gebruikers uiterst moeilijk te beheren of te verwijderen.

Zowel zombiecookies als supercookies zijn duidelijk onverenigbaar met de vereisten van de AVG en ePrivacy. Het gebruik ervan zou een schending vormen van de beginselen van transparantie, rechtmatigheid en dataminimalisatie.

Vergelijkingstabel

Type	Levensduur	Bereik	Is toestemming meestal vereist?	Belangrijkste toepassingen
Sessie	Alleen browsersessie	First-party	Alleen indien niet-essentieel	Inlogstatus, winkelmandje, CSRF-tokens
Permanent (first-party)	Dagen tot jaren	First-party	Meestal wel	Voorkeuren, analytics, aanmelding onthouden
Permanent (third-party)	Dagen tot jaren	Cross-site	Vrijwel altijd wel	Advertenties, retargeting, socialmediawidgets
Secure	Varieert	Alleen HTTPS	Hangt af van het doel	Elk gevoelig cookie
HttpOnly	Varieert	Alleen server-side	Hangt af van het doel	Sessie-ID's, authenticatietokens
SameSite=Strict	Varieert	Alleen same-site	Hangt af van het doel	CSRF-gevoelige handelingen
SameSite=Lax	Varieert	Same-site + navigatie op hoogste niveau	Hangt af van het doel	Algemeen sessiebeheer
SameSite=None	Varieert	Alle contexten (vereist Secure)	Vrijwel altijd wel	Third-party-embeds, cross-site-authenticatie

Wat dit betekent voor compliance

Het type cookie heeft directe gevolgen voor je complianceverplichtingen:

1. First-party-sessiecookies die strikt noodzakelijk zijn (inlogsessies, winkelmandjes, CSRF-tokens) zijn onder artikel 5(3) ePrivacy vrijgesteld van toestemmingsvereisten.
2. First-party permanente cookies voor analytics, voorkeuren of functionaliteit vereisen over het algemeen toestemming — al staan sommige toezichthouders onder specifieke voorwaarden beperkte uitzonderingen toe voor first-party-analytics.
3. Third-party-cookies van welke aard dan ook vereisen vrijwel altijd expliciete voorafgaande toestemming. Er zijn slechts zeer weinig legitieme uitzonderingen.
4. Beveiligingsattributen (Secure, HttpOnly, SameSite) veranderen de toestemmingsvereisten niet, maar het gebruik ervan getuigt van goede beveiligingspraktijken — wat op zichzelf al een AVG-vereiste is.

Precies weten welke cookies je website plaatst — en van welk type elk daarvan is — vormt de basis van elk complianceprogramma. De scanner van Passiro identificeert en classificeert automatisch elk cookie op je website, inclusief third-party-cookies die worden geplaatst door ingebedde scripts waarvan je je misschien niet eens bewust bent.

Nu we de verschillende soorten begrijpen, kijken we naar hoe cookies worden ingedeeld in toestemmingscategorieën — het classificatiesysteem dat bepaalt hoe ze in je cookiebanner verschijnen.