Wat zijn cookiebeveiligingsvlaggen?

Telkens wanneer uw WordPress-site een cookie plaatst — of het nu voor inlogsessies, winkelwagens, analyses of toestemmingsvoorkeuren is — kan die cookie een set beveiligingsvlaggen meedragen. Deze vlaggen vertellen de browser hoe met de cookie om te gaan: wanneer hem te versturen, wie hem mag lezen en over welke verbindingen hij mag reizen. Ze verkeerd instellen veroorzaakt zichtbaar geen problemen, maar opent de deur naar aanvallen die de meeste site-eigenaren pas opmerken als het te laat is.

De Secure-vlag

Een cookie met de Secure-vlag wordt alleen verzonden over HTTPS-verbindingen. De browser weigert simpelweg deze op te nemen in onversleutelde HTTP-verzoeken.

Set-Cookie: session_id=abc123; Secure

Waarom is dit belangrijk? Stel u een bezoeker voor die uw site bezoekt op de wifi van een koffietent. Als deze toevallig een pagina via gewoon HTTP laadt — bijvoorbeeld via een oude bookmark of een verkeerde redirectconfiguratie — zouden de cookies normaal in platte tekst over het netwerk reizen. Iedereen die dat wifi-verkeer afluistert, kan de sessiecookie buitmaken en zich voordoen als de gebruiker. Met de Secure-vlag houdt de browser de cookie in dat scenario volledig achter.

Aangezien uw WordPress-site sowieso op HTTPS hoort te draaien (en dat moet ook — er is in 2025 geen excuus meer), kost het instellen van deze vlag niets en voorkomt het een reële klasse aanvallen.

De HttpOnly-vlag

De HttpOnly-vlag verhindert dat JavaScript via document.cookie toegang heeft tot de cookie. De cookie wordt nog steeds normaal verstuurd met HTTP-verzoeken, maar geen enkel client-side script kan hem lezen of manipuleren.

Set-Cookie: session_id=abc123; HttpOnly

Deze vlag bestaat specifiek om de schade van Cross-Site Scripting (XSS)-aanvallen te beperken. Als een aanvaller erin slaagt JavaScript in uw pagina te injecteren — via een kwetsbare plugin, een reactieveld of een opgeslagen XSS-vector — is een van de eerste dingen die het script probeert document.cookie om sessietokens te stelen. Met HttpOnly ingesteld retourneert die aanroep niets voor de beschermde cookies.

Het voorkomt XSS zelf niet. Het verhelpt de onderliggende kwetsbaarheid niet. Maar het haalt de meest waardevolle prijs — sessiecookies — van de tafel, wat vaak het verschil maakt tussen overlast en een volledige accountovername.

De SameSite-vlag

Het SameSite-attribuut bepaalt het cross-site cookiegedrag. Het bepaalt of de browser een cookie verstuurt wanneer een verzoek afkomstig is van een ander domein dan het domein dat de cookie heeft geplaatst.

Er zijn drie mogelijke waarden:

• SameSite=Strict — De cookie wordt nooit verzonden bij cross-site verzoeken. Punt uit. Als iemand vanaf een externe pagina op een link naar uw site klikt, wordt de sessiecookie niet meegezonden bij dat eerste verzoek. Dit is de meest restrictieve instelling en kan gebruiksvriendelijkheidsproblemen veroorzaken (gebruikers lijken uitgelogd wanneer ze via externe links binnenkomen).
• SameSite=Lax — De cookie wordt meegezonden bij top-level navigaties (op een link klikken), maar niet bij ingebedde verzoeken zoals afbeeldingen, iframes of formulierverzendingen vanaf andere sites. Dit is de standaardinstelling van browsers sinds Chrome 80 (2020) en biedt een goede balans tussen beveiliging en gebruiksvriendelijkheid.
• SameSite=None — De cookie wordt verzonden bij alle verzoeken, ongeacht de oorsprong. Dit is nodig voor legitieme third-party cookiegebruiksgevallen (ingebedde betaalformulieren, SSO, advertenties), maar moet altijd worden gecombineerd met de Secure-vlag — browsers weigeren SameSite=None zonder Secure.

Set-Cookie: session_id=abc123; SameSite=Lax

De belangrijkste dreiging die SameSite aanpakt is Cross-Site Request Forgery (CSRF) — aanvallen waarbij een kwaadaardige site uw browser verleidt om geauthenticeerde verzoeken naar uw WordPress-site te doen zonder uw medeweten.

Alles samenvoegen

Voor authenticatie- en sessiecookies is de aanbevolen configuratie:

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

Elke vlag dekt een andere aanvalsvector af:

• Secure — voorkomt onderschepping op netwerkniveau
• HttpOnly — voorkomt diefstal op scriptniveau (XSS)
• SameSite — voorkomt cross-origin-misbruik (CSRF)

Het ontbreken van één ervan laat een gat. Ze werken als een team.

En third-party cookies?

Cookies die geplaatst worden door externe diensten die op uw site geladen zijn (analyses, chatwidgets, advertentiepixels) vallen niet onder uw directe controle. Hun beveiligingsvlaggen worden bepaald door de dienst die de cookie plaatst. Maar u moet zich er bewust van zijn — een third-party cookie zonder Secure of met SameSite=None creëert blootstelling op uw domein, ook al hebt u de cookie zelf niet geplaatst.

Dit is met name relevant voor GDPR-naleving: weten welke cookies op uw site worden geplaatst en hoe ze geconfigureerd zijn, is onderdeel van uw verantwoordelijkheid als sitebeheerder.

Hoe InspectWP helpt

InspectWP onderzoekt elke cookie die tijdens het laden van een pagina op uw WordPress-site wordt geplaatst en markeert die zonder de Secure-, HttpOnly- of SameSite-attributen. Het rapport toont elke cookie met de huidige vlaggen, zodat u snel kunt zien welke aandacht nodig hebben — of ze nu afkomstig zijn van WordPress core, plugins of third-party scripts.