Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is een beveiligingsrisico waarbij een aanvaller een ingelogde gebruiker ongemerkt opdrachten laat uitvoeren op een website waar die gebruiker is aangemeld. De aanval misbruikt het vertrouwen dat een website heeft in de browser van de gebruiker. Denk aan een medewerker die via een onschuldig lijkende link in een e-mail zonder het te weten bedrijfsgegevens wijzigt of betalingen autoriseert. Voor MKB-bedrijven met webshops, klantportalen of interne systemen vormt CSRF een direct risico op dataverlies, ongeautoriseerde transacties en reputatieschade.

Hoe werkt een CSRF-aanval in de praktijk

Een CSRF-aanval speelt zich af in vier stappen. Eerst logt een medewerker of klant in op een beveiligde website, bijvoorbeeld het beheerpaneel van een webshop of een klantportaal. De browser bewaart een sessiecookie om de gebruiker ingelogd te houden. Vervolgens opent diezelfde gebruiker in een ander tabblad een kwaadaardige website of klikt op een geprepareerde link in een e-mail. Die externe pagina bevat verborgen code die automatisch een verzoek stuurt naar de website waar de gebruiker nog is ingelogd. Omdat de browser het sessiecookie automatisch meestuurt, accepteert de website het verzoek als legitiem. Zo kan een aanvaller zonder wachtwoord producten wijzigen, bestellingen plaatsen of gebruikersrechten aanpassen. De gebruiker merkt vaak niets, omdat de actie in de achtergrond plaatsvindt.

Waarom CSRF-bescherming nu essentieel is voor webapplicaties

CSRF bestaat al sinds de vroege jaren 2000, maar blijft actueel omdat veel websites nog steeds onvoldoende beschermd zijn. Moderne webapplicaties werken steeds vaker met API's en externe integraties, wat het aanvalsoppervlak vergroot. In Nederland verplicht de Algemene Verordening Gegevensbescherming (AVG) bedrijven om passende technische maatregelen te treffen tegen ongeautoriseerde verwerking van persoonsgegevens. Een succesvolle CSRF-aanval kan leiden tot een datalek met meldplicht bij de Autoriteit Persoonsgegevens. Daarnaast eist de European Accessibility Act dat websites veilig en betrouwbaar zijn. Voor MKB-bedrijven betekent dit dat CSRF-bescherming geen nice-to-have is, maar een compliance-vereiste.

Wat CSRF-bescherming oplevert voor jouw website of webshop

Effectieve CSRF-bescherming voorkomt dat aanvallers misbruik maken van ingelogde sessies. Dit beschermt niet alleen klantgegevens, maar ook bedrijfskritische functies zoals voorraad- en prijsbeheer. Voor een webshop met 500 producten kan één ongeautoriseerde prijswijziging leiden tot duizenden euro's omzetverlies voordat je het opmerkt. Bij een professioneel gebouwde webshop worden CSRF-tokens standaard ingebouwd in formulieren en API-calls. Deze tokens zijn uniek per sessie en verifiëren dat elk verzoek echt van de gebruiker komt. Daarnaast voorkomt goede beveiliging dat je als bedrijf aansprakelijk wordt gesteld voor schade door een aanval. In combinatie met andere maatregelen zoals Content Security Policy en XSS-bescherming bouw je een robuuste verdedigingslinie op.

CSRF-bescherming is geen abstracte beveiligingsmaatregel, maar een concrete techniek die je in verschillende lagen van je website of applicatie inbouwt. De meest effectieve aanpak combineert meerdere methoden, afgestemd op hoe gebruikers met je systeem werken. Hieronder vier situaties waarin CSRF-bescherming het verschil maakt tussen een veilige en een kwetsbare applicatie.

Formulieren in webshops en klantportalen beveiligen

Elk formulier dat gegevens wijzigt of acties triggert, heeft CSRF-bescherming nodig. Denk aan een bestelformulier, een adreswijziging of een wachtwoordreset. De meest gebruikte methode is een CSRF-token: een unieke, willekeurige code die de server genereert bij het laden van de pagina en meestuurt in een verborgen veld. Wanneer de gebruiker het formulier verstuurt, controleert de server of het token klopt en nog geldig is. Een aanvaller die een verzoek vanaf een externe site probeert te sturen, heeft dit token niet en wordt geblokkeerd. In een webshop met duizenden bestellingen per maand voorkomt dit dat kwaadwillenden namens klanten producten bestellen of retourzendingen aanvragen. Moderne frameworks zoals WordPress, Laravel en Shopify bouwen CSRF-tokens automatisch in, maar alleen als je ze correct configureert.

API-endpoints beschermen tegen ongeautoriseerde calls

Steeds meer bedrijven gebruiken API's om data uit te wisselen tussen hun website, mobiele app en externe systemen. Een onbeveiligde API is kwetsbaar voor CSRF als de authenticatie alleen via cookies verloopt. De oplossing is om naast cookies ook een CSRF-token in de request header mee te sturen. Voor RESTful API's gebruik je vaak de 'X-CSRF-Token' header, die de client bij elke call moet meesturen. Bij een B2B-platform met 30 klanten die via API orders plaatsen, voorkomt dit dat een aanvaller namens een klant bestellingen manipuleert. Een alternatieve aanpak is om te werken met JSON Web Tokens (JWT) in plaats van sessiecookies, omdat JWT's niet automatisch door de browser worden meegestuurd. Dit vergt wel een andere authenticatie-architectuur, maar biedt meer controle over wie wat mag doen.

Administratieve functies in CMS- en CRM-systemen afdekken

Een CSRF-aanval op een beheerpaneel kan verstrekkende gevolgen hebben. Een aanvaller kan gebruikersrechten wijzigen, content verwijderen of malafide code injecteren. Voor een MKB-bedrijf met 12 medewerkers die toegang hebben tot het CMS betekent één succesvolle aanval dat de hele website gecompromitteerd kan zijn. CSRF-bescherming op admin-niveau werkt hetzelfde als bij formulieren, maar vereist extra aandacht voor langdurige sessies. Veel medewerkers blijven uren achter elkaar ingelogd, wat het risico vergroot. Een goede aanpak combineert CSRF-tokens met een automatische uitlog na inactiviteit en een herbevestiging bij kritieke acties zoals het verwijderen van data. Bij professionele webontwikkeling bouwen we dit standaard in, inclusief logging van verdachte activiteiten.

Wanneer CSRF-bescherming de juiste keuze is en wanneer niet

CSRF-bescherming is essentieel voor elke website of applicatie waar gebruikers inloggen en acties kunnen uitvoeren. Dit geldt voor webshops, klantportalen, intranet-omgevingen en alle CMS-systemen. Niet nodig is CSRF-bescherming voor volledig statische websites zonder inlogfunctie of voor publieke API's die alleen data ophalen zonder iets te wijzigen (GET-requests). Let op: een veelgemaakte fout is denken dat HTTPS alleen al voldoende bescherming biedt. HTTPS versleutelt data tijdens transport, maar voorkomt geen CSRF-aanvallen. Ook bedrijven die denken dat hun site te klein is om interessant te zijn voor aanvallers, onderschatten het risico. Geautomatiseerde aanvallen scannen het hele web en richten zich juist op kwetsbare MKB-sites omdat die vaak minder goed beveiligd zijn. Combineer CSRF-bescherming daarom altijd met andere maatregelen zoals tweefactorauthenticatie en regelmatige beveiligingsupdates.