Content Security Policy: wat doet CSP?

Een Content Security Policy is een set regels die uw server meestuurt met elke pagina. Per brontype (scripts, stylesheets, afbeeldingen, fonts, frames, connecties) zet u een allowlist: alleen deze domeinen, of alleen uw eigen origin. Volgens de MDN-gids over CSP weigert de browser alles wat buiten die lijst valt. Dat is de kern: niet "vertrouw wat er in de HTML staat", maar "vertrouw alleen wat de policy toelaat".

Dat raakt vooral cross-site scripting (XSS). Bij XSS slaagt een aanvaller erin script in uw pagina te krijgen: via een commentaarveld, een open redirect, een verouderde plugin. Zonder CSP voert de browser dat script gewoon uit. Met een strikte CSP mag het script niet van een vreemde bron komen, en mag inline script vaak niet eens starten. De injectie kan nog steeds in de markup zitten, maar de browser blokkeert de uitvoering.

OWASP benadrukt hetzelfde: CSP maakt kwetsbaarheden moeilijker uit te buiten, maar vervangt geen veilige code. Inputfilteren, output-encoding en updates blijven nodig. CSP is een vangnet, geen slot op de voordeur. Zie de OWASP CSP Cheat Sheet voor die nuance en voor aanbevolen directives.

CSP staat niet alleen. Zonder HTTPS en HSTS blijft verkeer onderschepbaar of blijft er een onversleutelde eerste hit mogelijk. Die basis vindt u in onze pagina's over SSL-certificaten en security headers. CSP beschermt wat er in de browser mag draaien; TLS beschermt wat er over de lijn gaat.

Er zijn twee headers die dezelfde policy-taal spreken. Content-Security-Policy dwingt af: overtredingen worden geblokkeerd. Content-Security-Policy-Report-Only doet hetzelfde inventarisatiewerk, maar laat alles nog door. De browser meldt alleen welke bronnen de policy zouden hebben geschonden.

Report-only is de veilige start. U inventariseert scripts van analytics, chat, betaalproviders, fonts en CDN's, schrijft een eerste policy, en zet die een week (of langer) op report-only. In de console of via een report-URI/report-to endpoint ziet u wat u nog mist. Pas als die lijst stilvalt, schakelt u over naar de afdwingende header.

Wie meteen enforce live zet, merkt het meestal via klachten: de chatwidget verdwijnt, de betaalknop doet niets, of Google Tag Manager stopt. Dat is geen reden om CSP over te slaan. Het is een reden om de report-only-fase serieus te nemen. U kunt tijdelijk beide headers naast elkaar gebruiken: report-only voor een strengere draft, enforce voor een mildere policy die al veilig is.

Een snelle naslag voor directives en keywords staat op de CSP Header Quick Reference. Gebruik die als checklist bij het schrijven van default-src, script-src, style-src en frame-ancestors; baseer de eindkeuze altijd op wat uw eigen site echt laadt.

De meest voorkomende zwakte is 'unsafe-inline' in script-src of style-src. Die keyword zegt: elke inline script of style mag. Daarmee haalt u een groot deel van de XSS-bescherming onderuit, want geïnjecteerde inline code is juist wat XSS vaak gebruikt. Hetzelfde geldt voor 'unsafe-eval' wanneer u eval of vergelijkbare constructies toestaat.

Beter: nonces of hashes. Een nonce is een willekeurige waarde per response die u in de header én op legitieme script-tags zet. Alleen tags met die nonce mogen draaien. Hashes werken voor vaste inline blokken waarvan u de inhoud kent. Frameworks zoals Next.js kunnen nonces per request genereren; dat is de moderne route naar een strengere policy zonder elke widget te breken.

Wildcards (https:) of te ruime host-lijsten zijn de tweede klassieker. Alles op HTTPS toestaan klinkt ruimhartig, maar laat nog steeds scripts van willekeurige sites toe. Beperk tot de domeinen die u echt nodig heeft. Vergeet ook frame-ancestors niet: zonder die directive (of zonder X-Frame-Options) blijft clickjacking via iframes mogelijk. CSP en de overige headers horen bij elkaar, niet als losse opties.

Tot slot: policy alleen op de homepage. Een CDN of reverse proxy die headers alleen op / zet, laat diepe URL's onbeschermd. Controleer na elke wijziging een productpagina, een blogpost en een accountroute, niet alleen de root.

De gratis WebYes-scan toetst security headers binnen de pijler veiligheid. CSP hoort daar expliciet bij: ontbreekt de header, dan ziet u dat terug (bijvoorbeeld als missing-csp). Staat er wel een policy maar met brede uitzonderingen zoals unsafe-inline of een wildcard, dan kan een weak-csp-bevinding volgen. Ook nonces/hashes en frame-ancestors komen in het rapport terug wanneer de engine die controles doet.

Voor het WebYes-keurmerk moet het gemiddelde over alle pijlers minstens 80 zijn, én elke pijler (inclusief veiligheid) minstens 60. Een ontbrekende of te losse CSP is een snelle manier om onder die vloer te zakken, zeker in combinatie met ontbrekende HSTS of een zwakke TLS-setup. Het rapport koppelt findings aan herstelrichting, zodat u niet alleen een score ziet maar ook wat u moet aanpassen.

De scan is gelabeld als beta en scant maximaal zes pagina's per run, met een dedupe-venster van zestig minuten per domein. Dat is genoeg om headers op representatieve URL's te zien, niet om elke edge-case in uw CDN te bewijzen. Gebruik de scan als diagnose; gebruik report-only in productie als u de policy aanscherpt.

Naast CSP kijkt dezelfde pijler naar HTTPS, HSTS en de andere headers die we in security headers toelichten. Wie alleen CSP toevoegt maar HTTP open laat, lost het verkeerde probleem op. Wie TLS goed heeft maar geen CSP, mist juist de XSS-laag.

Inventariseer eerst: open de netwerk-tab, noteer elk extern script, stylesheet, font en iframe. Neem ook third-party tags mee die via een tagmanager laden; die veranderen vaker dan uw eigen code. Zonder die lijst schrijft u een policy die morgen alweer breekt.

Schrijf daarna een minimale policy: default-src 'self', script-src en style-src met de bekende hosts, frame-ancestors 'self' (of strakker), en object-src 'none' als u geen plugins nodig heeft. Zet die eerst als Content-Security-Policy-Report-Only. Kijk rapporten na, vul gaten, herhaal.

Vervang unsafe-inline stap voor stap door nonces of hashes. Dat is vaak het lastigste deel, vooral bij oudere thema's of page builders die veel inline script injecteren. Plan dat als apart werk, niet als een avondklus naast een release.

Schakel pas daarna over naar enforce, en houd HSTS en HTTPS in sync. Een geldig SSL-certificaat met doorverwijzing, plus de headers uit onze security-headers-gids, plus een aangescherpte CSP: dat is de combinatie die in de praktijk de pijler veiligheid draagt. Test na elke wijziging opnieuw met de WebYes-scan.