jan-karel.nl
Home / Securitymaatregelen / Webbeveiliging / Client-Side Beveiliging

Client-Side Beveiliging

Client-Side Beveiliging

Code Met Grenzen, Productie Met Rust

Webrisico is zelden mysterieus. Het zit meestal in voorspelbare fouten die onder tijdsdruk blijven staan.

Voor Client-Side Beveiliging ligt de winst in context-gebonden output, browserbeperkingen en veilige frontend-baselines.

Dat maakt security minder een losse controle achteraf en meer een standaardkwaliteit van je product.

Directe maatregelen (15 minuten)

Waarom dit telt

De kern van Client-Side Beveiliging is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Verdediging: de complete client-side beveiligingschecklist

Maatregel Beschermt tegen Implementatie
CSRF tokens CSRF Token per sessie in elk muterend formulier; server-side validatie
SameSite cookies CSRF SameSite=Strict of Lax op sessiecookies
CORS policy CORS-misconfig Expliciete whitelist van origins; nooit reflected origin
X-Frame-Options Clickjacking DENY of SAMEORIGIN header
CSP frame-ancestors Clickjacking frame-ancestors 'none' of 'self'
Autorisatiechecks IDOR Server-side check: “mag deze gebruiker dit object zien?”
Content-Security-Policy XSS, data-exfil Restrictieve CSP; geen unsafe-inline
Cookie flags Sessiediefstal Secure; HttpOnly; SameSite=Lax

Laten we hier even stilstaan bij het feit dat de meeste client-side kwetsbaarheden die we in dit hoofdstuk hebben besproken, te voorkomen zijn met het instellen van een paar HTTP-headers. Een paar regels tekst. Meer niet. Geen complexe architectuur, geen dure tooling, geen team van tien security engineers. Gewoon headers.

Maar nee. We hebben liever uitgebreide “security awareness trainingen” waarbij iemand van HR een PowerPoint presenteert over het belang van “cyberhygiene”, terwijl de productie-API op datzelfde moment elke Origin header reflecteert als een papegaai die net geleerd heeft wat CORS is. De training kost vijftigduizend euro per jaar. De CORS-fix kost drie regels in nginx.conf. Raad eens welke we kiezen.

Samenvatting

De browser is een goedwillende maar naieve ambassadeur. Hij volgt de regels die hij krijgt, maar hij kan niet beoordelen of die regels kloppen. CORS-misconfiguratie vertelt hem dat elke buitenlandse delegatie vertrouwd is. CSRF laat hem documenten ondertekenen namens iemand anders. IDOR opent elke deur als je het juiste kamernummer noemt. En clickjacking legt een onzichtbare laag over alles.

De verdediging is niet ingewikkeld. Het is zelfs beschamend eenvoudig. Maar “eenvoudig” en “gedaan” zijn twee heel verschillende dingen.

In het volgende hoofdstuk verleggen we onze aandacht van de browser naar de poort: authenticatie en sessiemanagement. Want als de deur open is, maakt het niet meer uit hoe goed je ramen zijn.

Op de hoogte blijven?

Ontvang maandelijks cybersecurity-inzichten in je inbox.

← Webbeveiliging ← Home