Cookies zijn een mechanisme om “state” (sessie- en voorkeur-informatie) te bewaren in een browser via de HTTP-headers Set-Cookie (server → browser) en Cookie (browser → server). Dit is functioneel, maar vormt óók een structurele aanvals- en privacy-interface: cookies worden standaard automatisch meegestuurd met requests, wat sessiebeheer mogelijk maakt maar ook het fundament is onder o.a. sessie-kaping en CSRF. [1]

In Nederland vallen cookies en vergelijkbare technieken onder twee lagen regelgeving: (a) de “cookieregel” uit de Telecommunicatiewet (implementatie van de ePrivacyrichtlijn) die het opslaan/uitlezen van informatie op randapparatuur (zoals cookies) onder voorwaarden van duidelijke informatie + toestemming plaatst en expliciet techniekneutraal is; en (b) de AVG zodra cookies (of cookie-IDs) herleidbaar zijn tot personen (o.a. via “online identifiers”). [2]

De grootste compliance-fouten bij MKB zijn zelden “we hebben geen cookiebanner”, maar eerder: onvolledige (of verouderde) cookie-inventaris; scripts en third-party cookies die al vóór toestemming laden; “accept” als enige duidelijke optie; toestemming die niet aantoonbaar of niet intrekbaar is; en het ontbreken van informatie die wél vereist is, zoals bewaartermijnen en derde-toegang. [3]

De grootste security-fouten bij MKB zijn meestal technische defaults: sessiecookie zonder Secure en/of HttpOnly; te brede Domain/Path scope; geen (of verkeerd) SameSite; en te lange levensduur van sessies of “remember me”-cookies. Dit zijn geen cosmetische issues: een gestolen sessiecookie kan dezelfde impact hebben als gestolen inloggegevens totdat hij verloopt. [4]

Voor audits betekent dit: een “cookie- of consent-registratie” als document is onvoldoende. Je moet bewijs kunnen leveren dat (1) niet-noodzakelijke cookies technisch geblokkeerd zijn tot opt-in, (2) toestemming aantoonbaar voldoet aan AVG-criteria, en (3) security-attributen aantoonbaar correct zijn (via header- en netwerkchecks, niet via aannames). [5]

Definities en technische werking van cookies

Wat is een cookie technisch?
Een cookie is in de praktijk een kleine set key-value data die een website via HTTP kan laten opslaan in de browser (“user agent”) om zo sessies en voorkeuren te beheren over het grotendeels stateless HTTP-protocol. De formele specificatie van de HTTP-cookieheaders ligt bij de IETF. [7]

Headers en datastroom (kernmechanisme)
- Server stuurt: Set-Cookie: <naam>=<waarde>; <attributen…>
- Browser bewaart cookie in zijn “cookie store” en stuurt bij matching requests automatisch: Cookie: <naam>=<waarde>; ...
Dit is precies waarom cookies zowel bruikbaar (sessies) als gevaarlijk (automatisch meesturen) zijn. [1]

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123...; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: pref_lang=nl; Max-Age=31536000; Path=/; Secure; SameSite=Lax

# Bij een volgend request naar hetzelfde “site”-context:
GET /account HTTP/1.1
Host: voorbeeld.nl
Cookie: session_id=abc123...; pref_lang=nl

[8]

Levensduur: sessie vs persistent

• Als een cookie Max-Age of Expires heeft, is hij persistent (blijft bestaan tot expiratie, tenzij eerder gewist). Als beide aanwezig zijn, heeft Max-Age voorrang. [9]

• Zonder Max-Age en Expires mag de browser de cookie bewaren tot “de sessie voorbij is” (browser-definitie). Dit is in audits vaak een blind spot, omdat “session cookie” in de praktijk niet altijd “kort” betekent (browser restore, device sync, etc.). [9]

Scope: Domain/Path bepalen waar cookies heen “lekken”
Met Domain=site.example wordt de cookie naar die host en subdomeinen gestuurd; zonder Domain is hij “host-only” en gaat hij alleen terug naar de origin-host. [10]
Path beperkt naar welke URL-paden een cookie gestuurd wordt; te brede scope is een reëel risico als je meerdere applicaties op één domein draait (in MKB: webshop + CMS + supportportaal op hetzelfde hoofddomein). [11]

Transport en “secure context” realiteit
De cookie-inhoud is zonder beveiligd transport in principe leesbaar (“in clear text”) voor een afluisteraar en kan onderweg zelfs gemanipuleerd worden; daarom adviseren standaarden om cookies alleen over een secure kanaal te gebruiken en het Secure attribuut te zetten. [12]
In moderne web-beveiliging sluit dit aan bij het concept “secure contexts” uit de W3C web security specificaties (HTTPS als fundament voor vertrouwelijkheid/authenticiteit). [14]

Categorisering van cookie-typen

Waarom categoriseren lastig is (maar noodzakelijk)
Een cookie is vrijwel altijd tegelijk te classificeren op meerdere assen: doel (auth/analytics/marketing), levensduur (session/persistent), partij (first/third), en beveiligingsattributen (Secure, HttpOnly, SameSite, scope). In compliance en audits gebeurt het vaak te eendimensionaal (“functioneel vs tracking”), waardoor risico’s achterblijven. [15]

Assen die je minimaal afzonderlijk moet vastleggen bij een cookie-inventaris
Doelcategorie: essential/noodzakelijk, functioneel/voorkeur, security/fraud, analytics, marketing/tracking. [16]
Levensduur: session of persistent (Max-Age/Expires). [9]
Partij: first-party (door bezochte site gezet) of third-party (externe dienst). [17]
Transport en beveiliging: Secure, HttpOnly, SameSite, Domain, Path, en waar mogelijk cookie-prefixes. [18]

Vergelijkingstabel: cookie-doeltypen versus gebruik, risico en mitigatie

Bronnen voor definities/attributen en (minimale) technische mitigaties zijn o.a. RFC6265/6265bis en OWASP/NCSC guidance. [23]

Privacy, ePrivacy en AVG implicaties in de praktijk

Telecommunicatiewet en ePrivacy: het gaat om het apparaat, niet alleen persoonsgegevens
De Nederlandse “cookiebepaling” (Telecommunicatiewet art. 11.7a) is de implementatie van art. 5(3) van de ePrivacyrichtlijn en beschermt de persoonlijke levenssfeer door het opslaan van of toegang tot informatie op randapparatuur afhankelijk te maken van duidelijke/volledige informatie en toestemming. De wet is expliciet breder en techniekneutraal (dus ook relevant voor vergelijkbare opslag/lees-technieken). [24]

Het is cruciaal dat je dit niet versmalt tot “cookies = persoonsgegevens”. Het Hof van Justitie (Planet49) bevestigde dat de cookieregel ziet op “storing/access to information” op het apparaat, ongeacht of die informatie persoonsgegeven is. [25]

Wanneer is toestemming nodig (praktisch NL-perspectief)?

• Functionele/noodzakelijke cookies worden veelal als uitzondering gezien: je hoeft dan geen toestemming te vragen, maar je moet wél transparant zijn. [26]

• Voor analytics bestaat in Nederland een praktijk waarin “analytische cookies met weinig gevolgen voor de privacy” (of “geanonimiseerd meten”) zonder toestemming kunnen, mits de privacy-impact laag blijft en je dit goed uitlegt. [27]

• Voor tracking/marketing is toestemming in NL expliciet het uitgangspunt (“tracking cookies: altijd toestemming vereist”). [28]

AVG: wanneer worden cookies persoonsgegevens?
De AVG definieert persoonsgegevens mede als informatie waarmee iemand indirect identificeerbaar is, inclusief een “online identificator”. Cookie-ID’s vallen in veel realistische setups onder dit begrip zodra ze een gebruiker persistent herkennen of aan andere data te koppelen zijn. [29]

Geldige toestemming: opt-in, vrij, aantoonbaar, intrekbaar
De AVG stelt eisen aan toestemming (vrij, specifiek, geïnformeerd, ondubbelzinnig; actieve handeling). [30]
Pre-ticked boxes zijn geen geldige toestemming; active behaviour is vereist (Planet49). [31]
Cookie walls (toegang weigeren tenzij “accepteren”) zijn in de kern problematisch, omdat toestemming niet vrijelijk is als toegang tot dienst/functies afhankelijk is gemaakt van cookie-toestemming. Dit staat expliciet in de consent-richtsnoeren van de European Data Protection Board. [33]
Je moet toestemming net zo eenvoudig laten intrekken als geven (AVG art. 7 lid 3 en EDPB verdere uitwerking). [34]
Je moet kunnen aantonen dat toestemming is gegeven (AVG art. 7 lid 1). Dit is niet “handig”, dit is een expliciete bewijslast. [35]

Informatieplicht: de vaak vergeten velden
Planet49 is hier audit-technisch goud, omdat het scherp maakt wat “clear and comprehensive information” minimaal moet dekken. De informatie richting gebruiker moet óók bevatten:

• de duur/werking van cookies (bewaar- of “operation” duur), en

• of derden toegang hebben tot die cookies. [36]

Dit betekent praktisch: in je cookielijst en banner-informatie moeten “retentie” en “derden” niet als bijzaak, maar als kernvelden staan.

Verwerkingsverantwoordelijke / verwerker in cookie-ecosystemen
Als je als bedrijf beslist “waarom en hoe” persoonsgegevens (incl. cookie data) worden verwerkt, ben je verwerkingsverantwoordelijke; een verwerker verwerkt namens jou. Dit is relevant zodra je analytics-, marketing- of fraudediensten inkoopt (contracten, instructies, datagebruik voor eigen doelen). [37]

DPIA: wanneer is cookies inzetten ‘hoog risico’?
Als verwerking (zeker met nieuwe technologieën) waarschijnlijk een hoog risico inhoudt, is een DPIA verplicht. Tracking/profilering en grootschalige monitoring zijn typische triggers (zeker bij marketing/tracking stacks). [38]

Meldplicht datalek en cookies (sessiekaping als datalek-katalysator)
Als een sessiecookie wordt gestolen en daardoor onbevoegd toegang ontstaat tot persoonsgegevens, kan dit een datalek zijn. Dan geldt: meld aan de toezichthouder zonder onredelijke vertraging en zo mogelijk binnen 72 uur, tenzij het niet waarschijnlijk is dat er risico is voor rechten en vrijheden; en documenteer alle datalekken. [39] Voor Nederlandse meldpraktijk en beoordeling is de Autoriteit Persoonsgegevens de aangewezen toezichthouder. [41]

Security-implicaties en concrete mitigaties

Waarom cookies een security-‘hotspot’ zijn
De cookie-standaard erkent zelf dat cookies historische tekortkomingen hebben die security en privacy degraderen. [42]

Sessiecookies zijn, security-technisch, “bearer tokens”: wie de cookie heeft, heeft vaak de sessie. OWASP is expliciet: gestolen sessiecookies hebben dezelfde impact als gestolen authenticatiegegevens totdat de cookie verloopt. [43]

Typische aanvalsscenario’s en waarom MKB ze vaak onderschat

• Sessiekaping via XSS of onveilige transportpaden
  Zonder HttpOnly kan JavaScript (document.cookie) de sessiecookie lezen; bij XSS kan een aanvaller dus cookies exfiltreren. [44]

• Zonder Secure kan een browser misleid worden om een sessiecookie over HTTP te sturen; OWASP benoemt dat “alleen HTTPS gebruiken” niet genoeg is als Secure ontbreekt. [44]

• De standaardspecificatie benadrukt bovendien dat cookieheaders zonder secure channel “in the clear” gaan en dat servers Secure breed moeten toepassen. [45]

sequenceDiagram
    participant U as Gebruiker (browser)
    participant S as Website (server)
    participant A as Aanvaller

    U->>S: Login (HTTPS)
    S-->>U: Set-Cookie: session_id=... (zonder HttpOnly/Secure)
    Note over U: Cookie is door JS leesbaar en kan ook via HTTP lekken

    A->>U: Injecteert script (XSS) of dwingt HTTP-call
    U-->>A: Exfiltreert session_id (document.cookie of via HTTP)
    A->>S: Request met gestolen Cookie: session_id=...
    S-->>A: Toegang als gebruiker (sessiekaping)

[46]

CSRF: ‘automatisch meesturen’ is het probleem
CSRF werkt omdat browsers cookies automatisch meesturen; zonder extra “challenge-response” (CSRF token/headers) kan de server forged requests niet onderscheiden van echte. [47]
SameSite helpt, maar is geen complete oplossing; RFC6265bis adviseert expliciet om ook server-side defenses zoals CSRF tokens te blijven gebruiken. [48]

Minimale technische baseline voor MKB-websites

• Cookie-attributen die je (bijna) altijd moet afdwingen
  Secure: alleen mee over HTTPS; essentieel tegen MitM-sessie-lekken. [49]

• HttpOnly: voorkomt uitlezen via scripts; essentieel tegen cookie theft bij XSS (let op: het verhindert niet dat de browser de cookie meestuurt). [44]

• SameSite: defense-in-depth tegen CSRF en cross-site leakage, met duidelijke trade-offs: - Strict: sterkst, maar kan users verrassen bij navigaties vanaf andere sites. [50]

• Lax: vaak pragmatische default voor sessies. [51]

• None: nodig voor embedded cross-site use-cases (widgets, sommige SSO flows), maar mag alleen in combinatie met Secure; anders negeren browsers de cookie. [52]

Scope hardening: Domain/Path en cookie-prefixes
Te brede Domain-scoping maakt subdomein-aanvallen en session fixation realistischer, zeker bij “rommelige” MKB-domeinlandschappen. OWASP raadt een restrictieve scope aan (liefst geen Domain, en Path zo smal mogelijk). [11]

Gebruik waar mogelijk cookie-prefixes als “guardrails”:
- __Secure- vereist Secure. [53]
- __Host- vereist Secure, Path=/ en geen Domain (host-only). [54]

# Sterke sessiecookie voor de meeste webapps
Set-Cookie: __Host-session_id=RANDOM_LONG; Path=/; Secure; HttpOnly; SameSite=Lax

# Cross-site (bijv. embedded login) — alleen als functioneel echt nodig
Set-Cookie: auth_embed=RANDOM_LONG; Path=/; Secure; HttpOnly; SameSite=None

[55]

Server-side sessies boven “rijke cookies”
De standaard adviseert waar nodig cookie-inhoud te versleutelen/te signeren, maar benadrukt impliciet een harde realiteit: zelfs dan kan een aanvaller cookies replayen of “transplanteren” naar een andere agent. Dit is een extra argument om cookies te beperken tot random identifiers met server-side state, en om aanvullend sessie-validatie of anomaliedetectie te overwegen. [56]

Aanvullende detectie (pragmatisch voor MKB)
OWASP beschrijft een praktische detectiehoek: bij gebruik van gestolen sessiecookies veranderen vaak omgevingskenmerken (IP-regio, user-agent, taal, tijd). Dit is geen perfecte detectie (false positives), maar kan bij MKB een groot deel van “silent hijacking” zichtbaar maken. [57]

Auditaanpak, acceptabel bewijs en checklist voor MKB-managers

Veelvoorkomende MKB-fouten die audits missen

Consent wordt ‘juridisch’ ontworpen maar niet ‘technisch’ afgedwongen
De banner toont opties, maar third-party scripts laden al vóór toestemming (network calls naar trackers/ads, cookies gezet in background). Dit is precies waarom screenshots van banners als auditbewijs zwak zijn. (Je moet technisch aantonen dat niet-noodzakelijke cookies niet gezet/uitgelezen worden vóór opt-in.) [58]

Een concrete tip is zelf een eerste scan uit te voeren, bijvoorbeeld met de gratis open-source tool Webbkoll (https://webbkoll.5july.net) of via de netwerk-tab van de browser-DevTools bij een eerste bezoek in incognitomodus. (De eerder populaire scanner 2GDPR biedt geen gratis publieke checks meer aan.)

“Intrekken” is verstopt of omslachtig
AVG vereist dat intrekken even eenvoudig is als geven; de EDPB werkt dit uit bij online interfaces (één klik geven = ook laagdrempelig online intrekken, zonder nadeel). In MKB zie je vaak “mail ons” of “bel tijdens kantooruren”. [34]

Cookie-informatie mist “duur” en “derde-toegang”
Planet49 maakt duidelijk dat dit geen nice-to-have is: duur van cookies en toegang door derden horen in de informatieverplichting. In MKB-cookielijsten ontbreken deze velden opvallend vaak, of zijn ze generiek (“13 maanden”) zonder per cookie. [36]

Security-attributen worden aangenomen in plaats van gemeten
“Wij gebruiken HTTPS” wordt soms als voldoende gezien, terwijl het ontbreken van Secure of HttpOnly juist het praktische lek creëert. OWASP en NCSC zijn hier expliciet over. [59]

Mermaid flow: hoe een aantoonbare consent flow er auditbaar uitziet

flowchart TD
  A[Pagina load] --> B{Consent cookie aanwezig?}
  B -- Ja --> C[Pas voorkeuren toe]
  C --> D[Laad alleen toegestane categorieën scripts]
  B -- Nee --> E[Laad alleen essential cookies/scripts]
  E --> F[Toon cookiebanner met granulariteit]
  F --> G{Keuze gebruiker}
  G -- Weigeren --> H[Blokkeer niet-essential]
  H --> I[Sla keuze op: consent cookie + consent log]
  G -- Accepteren (selectief) --> J[Activeer gekozen categorieën]
  J --> I
  I --> K[Maak intrekken net zo eenvoudig als geven]

[60]

Tabel: wat auditors vaak accepteren versus wat je echt moet kunnen aantonen

Concrete auditvragen voor MKB (interview, documentatie, technische checks)

Interview (praktijk boven theorie)

• Wie is eigenaar van “cookies & tracking” (business én IT)? [67]

• Welke third-party diensten kunnen cookies zetten via jullie site (embedded content, tags, analytics, chat)? [68]

• Welke use-cases vereisen écht SameSite=None (cross-site) en waarom? [52]

• Hoe kan een bezoeker toestemming intrekken in maximaal twee klikken? Laat het live zien. [34]

Documentatie

• Toon de cookielijst met per cookie: doel, bewaartermijn, derde-toegang en categorie. [36]

• Toon consent-log structuur (velden) en bewaartermijn; hoe toon je “aantoonbaarheid” conform AVG art. 7 lid 1? [35]

• Is er een DPIA of DPIA-screening voor tracking/profilering? [69]

• Is er een datalek-proces dat expliciet cookie-/sessiekaping als scenario meeneemt? [70]

Technische checks (de enige manier om ‘pre-consent’ echt te toetsen)

• Netwerktrace eerste load (incognito): welke cookies worden gezet, welke domains worden aangeroepen? [71]

• Vergelijk “weigeren” vs “accepteren”: verschillen in netwerkcalls/cookies. [72]

• Inspecteer Set-Cookie-headers op Secure, HttpOnly, SameSite, Domain, Path, cookie-prefixes. [73]

Afsluitende checklist voor MKB Security Officers en bedrijfseigenaren

Wijs één proceseigenaar aan voor “cookies, tracking en consent” (met mandaat over marketing én IT). [67] Bonuspunten als je die persoon intern ‘het cookiemonster’ noemt.

• Maak een reproduceerbare cookie-scan (meerdere pagina’s + login/checkout) en update dit bij iedere release. [7]

• Leg per cookie vast: doel, categorie, partij, lifetime, third-party access, en of consent vereist is. [74]

• Zorg dat “weigeren” functioneel gelijkwaardig zichtbaar/bruikbaar is als “accepteren”; vermijd cookiewalls. [33]Blokkeer technisch alle niet-noodzakelijke scripts en cookies tot opt-in (bewijsbaar via netwerklogs). [75]

• Maak intrekken net zo eenvoudig als geven (zelfde interface, geen e-mail/telefoon als primaire route). [34]

• Log toestemming zodanig dat je hem kunt aantonen (AVG art. 7 lid 1), inclusief versie/tekst van de consentvraag. [34]

• Vermeld in cookie-informatie minimaal bewaartermijn en derde-toegang; Planet49 maakt dit expliciet relevant. [36]

• Zet voor sessie- en auth-cookies standaard: Secure; HttpOnly; SameSite=Lax (tenzij onderbouwd anders). [76]

• Gebruik SameSite=None alleen als je het echt nodig hebt; combineer altijd met Secure (anders wordt cookie genegeerd). [77]

• Beperk Domain/Path en gebruik waar mogelijk __Host-/__Secure- prefixes om misconfiguraties te laten falen. [78]

• Houd sessies kort, roteer tokens bij login/privilege change en beëindig sessies bij logout. [4]

• Voeg detectie toe op “session cookie misuse” (IP/UA afwijking) als pragmatische compensating control. [57]

• Beoordeel of tracking/profilering een DPIA vereist; documenteer de afweging. [69]

• Neem “sessiekaping via cookie theft” expliciet op in je datalek-proces (72 uur, risicoafweging, documentatieplicht). [39]

• Voor Nederlandse toezichtcontext: betrek rollen en interpretaties van de Autoriteit Consument & Markt (ACM) en de AP in je compliance-risicobeeld. [80]

• Gebruik voor security-baselines en toetsing guidance van Nationaal Cyber Security Centrum, OWASP[4] en ENISA[17] als “minimum referentiekader” wanneer je geen eigen securityteam hebt. [84]

Geraadpleegde bronnen en resources

[1] [7] [23] [42] [71] https://datatracker.ietf.org/doc/html/rfc6265

[2] [24] [67] [80]  https://zoek.officielebekendmakingen.nl/kst-33902-3.html

[3] [33] [58] [72] https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_nl.pdf

[4]  [11] [18] [19] [44] [46] [49] [59] [64] [73] [76] [78]  https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

[5]  [29] [30] [34] [35] [37] [38] [39] [60] [63] [65] [66] [69] [70]  https://eur-lex.europa.eu/legal-content/NL/TXT/HTML/?uri=CELEX%3A02016R0679-20160504

[8] [9] [10] [12]  [45] [48] [50] [51] [52] [53] [54] [55] [56] [77] https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html

[14] https://www.w3.org/TR/secure-contexts/

[15] [16] [21] [84] https://www.ncsc.nl/webapplicaties/gebruik-van-cookies

[17] https://www.enisa.europa.eu/about-enisa/cookies

[20] [47] https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

[22] https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/cookies-en-online-tracking/

[25] [31] [36]  [61] [62] [74] [75] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A62017CJ0673

[26] [27] [28] https://www.rijksoverheid.nl/onderwerpen/telecommunicatie/vraag-en-antwoord/mag-een-website-ongevraagd-cookies-plaatsen

[41] https://www.autoriteitpersoonsgegevens.nl/themas/beveiliging/datalekken/datalek-wel-of-niet-melden

[43] [57] https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html

[68] https://www.communicatierijk.nl/vakkennis/rijkswebsites/verplichte-richtlijnen/telecommunicatiewet-cookiewet