Content Security Policy (CSP) voor de backend
Leer hoe backendconfiguraties invloed kunnen hebben op Content Security Policy (CSP) om client-side aanvallen zoals XSS te beperken.
Content Security Policy (CSP) voor de backend is een gratis Veilig coderen en de OWASP Top 10 voor backends-les op CoddyKit. Dit is les 3 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Veilig coderen en de OWASP Top 10 voor backends. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Veilig coderen en de OWASP Top 10 voor backends bevat in totaal 4 lessen.
De rol van de backend bij CSP
Welkom bij Content Security Policy (CSP) voor de backend! Misschien denk je dat CSP alleen voor frontendontwikkelaars is, maar de backend speelt een cruciale rol.
CSP is een beveiligingsstandaard die clientaanvallen zoals Cross-Site Scripting (XSS) helpt voorkomen. Dit gebeurt door de browser te vertellen welke bronnen (scripts, stijlen en afbeeldingen) mogen worden geladen en uitgevoerd.
De backend is verantwoordelijk voor het aanleveren van deze regels aan de browser.
Hoe de backend CSP aanlevert
De backend levert CSP-regels aan de browser met een speciale HTTP-responsheader met de naam Content-Security-Policy. Wanneer de browser deze header ontvangt, handhaaft hij de regels die erin staan.
Dit betekent dat je backendtoepassing rechtstreeks het beveiligingsbeleid voor je frontend bepaalt. Laten we bekijken hoe een backend deze header kan instellen.
De CSP-header instellen
In een backendtoepassing voeg je de CSP-header doorgaans toe aan je HTTP-respons. Dit voorbeeld simuleert een backend die een eenvoudige CSP-header verzendt.
De richtlijn default-src 'self' staat alleen bronnen toe die afkomstig zijn van dezelfde oorsprong als het document.
public class BackendCspExample {
public static void main(String[] args) {
System.out.println("HTTP/1.1 200 OK");
System.out.println("Content-Type: text/html");
System.out.println("Content-Security-Policy: default-src 'self';");
System.out.println("");
System.out.println("<!-- Your secure HTML content goes here -->");
}
}Belangrijke CSP-richtlijnen voor de backend
Als backendontwikkelaar definieer je vaak richtlijnen die verschillende brontypen beheren. Enkele veelgebruikte zijn:
script-src: geeft geldige bronnen voor JavaScript op.style-src: geeft geldige bronnen voor stijlbladen op.img-src: geeft geldige bronnen voor afbeeldingen op.connect-src: beperkt URL's die met scriptinterfaces kunnen worden geladen (bijvoorbeeld AJAX en WebSockets).
Elke richtlijn kan meerdere toegestane bronnen hebben, zoals 'self', https://example.com of 'unsafe-inline' (die je over het algemeen moet vermijden).
Inline scripts beperken met nonces
Een veelgebruikte aanvalsvector voor XSS is het injecteren van inline scripts. CSP kan deze blokkeren, maar soms zijn inline scripts noodzakelijk.
De backend kan voor elke aanvraag een unieke, cryptografisch veilige nonce (Number Used Once) genereren. Deze nonce wordt toegevoegd aan zowel de CSP-header als de toegestane inline <script>-tags.
Noncegeneratie door de backend
Zo kan een backend een nonce genereren. Deze nonce wordt vervolgens opgenomen in de Content-Security-Policy-header (bijvoorbeeld script-src 'nonce-YOUR_NONCE_HERE') en weergegeven in de HTML-script-tag.
De browser voert alleen inline scripts uit die een overeenkomend nonce-attribuut hebben.
import java.util.Base64;
import java.security.SecureRandom;
public class NonceGenerator {
public static void main(String[] args) {
SecureRandom random = new SecureRandom();
byte[] nonceBytes = new byte[16]; // 16 bytes for a good nonce
random.nextBytes(nonceBytes);
String nonce = Base64.getEncoder().encodeToString(nonceBytes);
System.out.println("Generated Nonce: " + nonce);
System.out.println("\nUse this in your CSP header:");
System.out.println("Content-Security-Policy: script-src 'self' 'nonce-" + nonce + "';");
System.out.println("\nAnd in your HTML:");
System.out.println("<script nonce=\"" + nonce + "\">alert('Hello!');</script>");
}
}CSP-rapportage: `report-to`
CSP draait niet alleen om blokkeren; zichtbaarheid is ook belangrijk. De backend kan een rapportage-eindpunt opgeven met de richtlijn report-to (of de oudere report-uri).
Als een browser de CSP schendt (bijvoorbeeld door te proberen een script van een niet-geautoriseerde bron te laden), stuurt hij een JSON-rapport naar dit backend-eindpunt. Je backend kan deze rapporten vervolgens loggen en analyseren om mogelijke aanvallen of onjuist geconfigureerd beleid te detecteren.
CSP integreren met frameworks
Moderne backendframeworks bieden vaak handige manieren om CSP-headers te beheren zonder tekenreeksen handmatig samen te voegen.
- Spring Security (Java): heeft speciale configuraties voor HTTP-beveiligingsheaders, waaronder CSP.
- Helmet (Node.js/Express): is middleware die Express-apps helpt beveiligen door verschillende HTTP-headers in te stellen, waaronder CSP.
- Django (Python): kan CSP-headers instellen via middleware of specifieke bibliotheken.
Deze hulpmiddelen vereenvoudigen de implementatie en helpen ervoor te zorgen dat best practices worden gevolgd.
CSP voor XSS-preventie (backendperspectief)
Vanuit backendperspectief voegt correct geconfigureerde CSP een krachtige beschermingslaag tegen XSS toe. Zelfs als een aanvaller erin slaagt schadelijke inhoud in je HTML te injecteren, kan CSP voorkomen dat de browser deze uitvoert.
Door de Content-Security-Policy-header te beheren, bepaalt je backend welke inhoud veilig is. Zo wordt de impact van kwetsbaarheden aan de clientzijde aanzienlijk beperkt.
CSP-headeruitdaging
Stel dat een backendservice scripts alleen vanaf het eigen domein en vanaf cdn.example.com moet toestaan. Met welke CSP-richtlijn bereik je dit het best?
Samenvatting: backend en CSP
Je hebt geleerd dat Content Security Policy (CSP) een cruciale beveiligingslaag is die door de backend wordt aangeleverd via de Content-Security-Policy-HTTP-header.
- De backend stelt CSP-headers in om het laden van bronnen te beheren.
- Richtlijnen zoals
script-srcdefiniëren toegestane bronnen. - Nonces zijn door de backend gegenereerde tokens waarmee specifieke inline scripts veilig kunnen worden toegestaan.
- De backend kan schendingsrapporten verzamelen via
report-to. - Frameworks vereenvoudigen de implementatie van CSP.
Door CSP actief te beheren, versterken backendontwikkelaars de bescherming van hun toepassing tegen clientaanvallen zoals XSS aanzienlijk.
Leer Veilig coderen en de OWASP Top 10 voor backends 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
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Content Security Policy (CSP) voor de backend” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Veilig coderen en de OWASP Top 10 voor backends, waaronder “Content Security Policy (CSP) voor de backend”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Veilig coderen en de OWASP Top 10 voor backends bevat in totaal 4 lessen.
Wat leer ik in “Content Security Policy (CSP) voor de backend”?
Leer hoe backendconfiguraties invloed kunnen hebben op Content Security Policy (CSP) om client-side aanvallen zoals XSS te beperken. Je oefent met Veilig coderen en de OWASP Top 10 voor backends 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 Veilig coderen en de OWASP Top 10 voor backends te beginnen?
Ervaring vooraf is niet nodig. Veilig coderen en de OWASP Top 10 voor backends 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 3 van 4.
Hoe lang duurt de les “Content Security Policy (CSP) voor de backend”?
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 Veilig coderen en de OWASP Top 10 voor backends?
Ja. Elke les over Veilig coderen en de OWASP Top 10 voor backends 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
- Geavanceerde SQLi- en NoSQLi-technieken
- Uitgebreide strategieën voor invoervalidatie
- Content Security Policy (CSP) voor de backend
- Command- en LDAP-injection voorkomen