CSRF: SameSite-cookies en tokens
Begrijp hoe Cross-Site Request Forgery cookies misbruikt, gebruik SameSite=Strict/Lax om dit te voorkomen en voeg synchronisatortokens toe voor extra bescherming.
CSRF: SameSite-cookies en tokens is een gratis Frontend Academy-les op CoddyKit. Dit is les 2 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Frontend Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Frontend Academy bevat in totaal 4 lessen.
Wat is CSRF?
Cross-site requestvervalsing: een aanvaller laat de browser van een ingelogde gebruiker een verzoek naar je site sturen. De browser voegt de cookies van de gebruiker toe — de server denkt dat het een legitiem verzoek van de gebruiker is.
Klassieke CSRF-aanval
De gebruiker is ingelogd bij bank.com. Die bezoekt evil.com. evil.com verstuurt een verborgen formulier naar bank.com/transfer met het rekeningnummer van de aanvaller. De browser stuurt de sessiecookie van bank.com automatisch mee. De server maakt het geld over.
Het vertrouwensprobleem
CSRF werkt omdat browsers cookies automatisch meesturen bij verzoeken naar een andere origin. Zonder extra bescherming kan de server niet zien dat het verzoek van een kwaadaardige site afkomstig is.
SameSite-cookies — de moderne oplossing
Het cookieattribuut SameSite bepaalt wanneer cookies worden meegestuurd bij verzoeken naar een andere origin. Strict: nooit bij een andere origin meegestuurd. Lax (standaard in Chrome): alleen meegestuurd bij top-level GET-navigatie. None: altijd meegestuurd (moet ook Secure zijn).
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=LaxSameSite=Lax als standaard
Chrome stelt alle cookies standaard in op Lax als er geen SameSite is opgegeven. Dit blokkeert de meeste CSRF-aanvallen — maar je moet de waarde toch expliciet instellen.
SameSite=Strict voor maximale beveiliging
Gebruik Strict voor de gevoeligste cookies, zoals beheerderssessies en banktransacties. Nadeel: de gebruiker lijkt uitgelogd wanneer die via een link van een andere site binnenkomt.
CSRF-tokens (synchronisatiepatroon)
Gebruik CSRF-tokens voor ondersteuning van oudere browsers of extra veiligheid. De server genereert een willekeurig token, voegt het toe aan de pagina en vereist het bij elk verzoek dat de toestand wijzigt.
// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">
// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
method: 'POST',
headers: { 'X-CSRF-Token': token },
body: JSON.stringify({ amount: 100 })
});
// Server verifies the X-CSRF-Token header matches the user's sessionDubbele cookie-inzending
De server stelt een CSRF-cookie in (niet HttpOnly, zodat JavaScript die kan lezen). De client leest de cookie en stuurt de waarde in een header. De server controleert of de cookie overeenkomt met de header. Een aanvaller kan de cookie niet vanaf een andere origin lezen en kan de header dus niet namaken.
Waarom dit werkt
De evil.com-site van de aanvaller kan geen cookies van bank.com lezen (het Same-Origin Policy-beleid). Daarom kan de aanvaller de header X-CSRF-Token niet instellen. Het verzoek wordt door de tokencontrole op de server afgewezen.
CSRF in SPA's met Bearer-tokens
Als je je verifieert met Authorization: Bearer <jwt> dat in het geheugen is opgeslagen (niet in een cookie), is CSRF niet van toepassing — browsers sturen headers niet automatisch mee. Afweging: je bent kwetsbaarder voor XSS, omdat tokens die toegankelijk zijn voor JavaScript kunnen worden gestolen.
Truc met een aangepaste header
Bij API's die alleen JSON met een aangepaste header accepteren, zoals X-Requested-With, sturen browsers een voorafgaande OPTIONS-aanvraag — en voegen ze geen cookies toe aan die voorafgaande aanvraag. Dit blokkeert CSRF via eenvoudige formulieren effectief.
Idempotente versus muterende eindpunten
CSRF heeft vooral gevolgen voor verzoeken die de toestand wijzigen (POST, PUT, DELETE). GET-eindpunten horen idempotent te zijn — dus geen neveneffecten te hebben — zodat een vervalst GET-verzoek geen schade kan aanrichten.
Snelle controle
Welke SameSite-cookiewaarde voorkomt standaard dat cookies bij de meeste verzoeken van andere sites worden meegestuurd in moderne browsers?
Samenvatting: CSRF-preventie
Stel SameSite=Lax (of Strict) in voor sessiecookies — dit blokkeert de meeste CSRF-aanvallen. Voeg HttpOnly + Secure toe. Gebruik CSRF-tokens (het synchronisatiepatroon of dubbele cookie-inzending) voor extra bescherming. Bearer-tokens in headers voorkomen CSRF, maar verhogen het XSS-risico. De truc met een aangepaste header forceert een voorafgaande aanvraag. Maak GET-verzoeken idempotent.
Leer HTML met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 41
- Lessen
- 163
Veelgestelde vragen
Is de les “CSRF: SameSite-cookies en tokens” gratis?
Ja — de volledige tekst van “CSRF: SameSite-cookies en tokens” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Frontend Academy wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Frontend Academy bevat in totaal 4 lessen.
Wat leer ik in “CSRF: SameSite-cookies en tokens”?
Begrijp hoe Cross-Site Request Forgery cookies misbruikt, gebruik SameSite=Strict/Lax om dit te voorkomen en voeg synchronisatortokens toe voor extra bescherming. Je oefent met Frontend Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Frontend Academy te beginnen?
Ervaring vooraf is niet nodig. Frontend Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.
Hoe lang duurt de les “CSRF: SameSite-cookies en tokens”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Frontend Academy?
Ja. Elke les over Frontend Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- XSS-preventie: outputencoding en CSP
- CSRF: SameSite-cookies en tokens
- Content Security Policy: nonce en hash
- OAuth-flows vanuit de frontend