Cross-Site Scripting (XSS) blijft jaar na jaar in de OWASP Top 10 staan. Content Security Policy (CSP) is een krachtige HTTP-header die uw browser vertelt welke bronnen wel en niet geladen mogen worden. In dit artikel leert u hoe u CSP effectief implementeert, veelgemaakte fouten voorkomt en uw webapp beschermt tegen XSS-aanvallen.
Wat is Content Security Policy?
Content Security Policy is een W3C-standaard die via een HTTP-header of meta-tag aan de browser communiceert welke bronnen vertrouwd zijn. Wanneer een script, stylesheet of afbeelding van een niet-geautoriseerde bron probeert te laden, blokkeert de browser dit automatisch. Dit maakt CSP een van de krachtigste verdedigingsmechanismen tegen XSS, clickjacking en data-injectieaanvallen.
CSP werkt met directives zoals script-src, style-src, img-src en default-src die elk aangeven welke bronnen voor dat type content zijn toegestaan. U kunt specifieke domeinen whitelisten, nonces of hashes gebruiken voor inline scripts, en zelfs rapportage inschakelen om schendingen te monitoren zonder verkeer te blokkeren.
# Voorbeeld CSP-header in Nginx
add_header Content-Security-Policy "
default-src 'self';
script-src 'self' 'nonce-abc123' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.example.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
";Veelgemaakte CSP-fouten en hoe ze te voorkomen
De meest voorkomende fout bij CSP-implementatie is het gebruik van unsafe-inline en unsafe-eval voor scripts. Deze directives ondermijnen het hele doel van CSP, omdat ze precies de aanvalsvectoren openlaten die CSP zou moeten blokkeren. Gebruik in plaats daarvan nonce-based of hash-based policies die specifieke inline scripts toestaan.
Een andere veelgemaakte fout is een te brede script-src directive, zoals het whitelisten van hele CDN-domeinen. Als een aanvaller een kwaadaardig script kan hosten op hetzelfde CDN, omzeilt hij uw CSP volledig. Gebruik strict-dynamic in combinatie met nonces voor een robuustere aanpak.
- Vermijd unsafe-inline en unsafe-eval — gebruik nonces of hashes
- Start met Content-Security-Policy-Report-Only om te testen zonder te blokkeren
- Gebruik strict-dynamic voor compatibiliteit met moderne frameworks
- Configureer report-uri of report-to voor continue monitoring
- Vergeet frame-ancestors niet — het vervangt X-Frame-Options
- Implementeer base-uri om base tag hijacking te voorkomen
CSP in productie: monitoring en iteratie
Een effectieve CSP is geen eenmalige configuratie maar een doorlopend proces. Begin met Content-Security-Policy-Report-Only om schendingen te verzamelen zonder functionaliteit te breken. Analyseer de rapporten, verfijn uw policy, en schakel pas over naar enforcement wanneer u zeker bent dat alle legitieme bronnen zijn toegestaan.
Gebruik tools zoals Google's CSP Evaluator of Report URI om uw policy te valideren en rapporten te aggregeren. In een CI/CD-pipeline kunt u automated tests toevoegen die controleren of de CSP-header aanwezig en correct is na elke deployment. Vergeet ook niet om uw CSP te updaten wanneer u nieuwe third-party services integreert.
Pro Tip
Begin vandaag met het toevoegen van een Content-Security-Policy-Report-Only header aan uw applicatie. Gebruik een nonce-based aanpak voor scripts en configureer report-to om schendingen te monitoren. Binnen een week heeft u voldoende data om een strikte CSP in te voeren die 90% van alle XSS-aanvallen blokkeert.
Deel dit artikel