Een Content Security Policy (CSP) is een extra beveiligingslaag die we gebruiken op websites om het risico van aanvallen zoals cross-site scripting (XSS) en data-injectie te verminderen. Het definieert welke bronnen en acties zijn toegestaan op een webpagina, waardoor we het moeilijker maken voor aanvallers om schadelijke code uit te voeren.

Een CSP implementeren we door middel Van Een HTTP-header die we aan de serverreactie toevoegen. Deze header bevat een reeks beleidsregels die aangeven welke bronnen (zoals scripts, stijlbladen, afbeeldingen, enz.) zijn toegestaan om te laden en uit te voeren op de webpagina. Hierdoor kunnen webontwikkelaars specifieke domeinen en bronnen identificeren die de site veilig kan gebruiken. Hierdoor verminderen we het risico van het laden van kwaadwillende scripts vanaf andere locaties.

CSP betekenis

CSP’s zijn een krachtig hulpmiddel voor het verbeteren van de beveiliging van websites. Ze vereisen echter zorgvuldige configuratie om ervoor te zorgen dat ze de functionaliteit van de site niet verstoren. Het implementeren van een goed ontworpen CSP kan helpen bij het beschermen van gebruikers tegen verschillende soorten aanvallen en het verbeteren van de algehele beveiliging van een website.

Is een Content Security Policy dus harde code en niet een beleid?

Het voorbeeld, wat als laatste in dit artikel staat, is de daadwerkelijke content security policy header die naar de browser wordt gestuurd en die de browser vertelt welke bronnen zijn toegestaan op de webpagina. Dit beschouwen we niet direct als “harde code”, maar eerder als instellingen voor een beveiligingsbeleid dat we afdwingen door de browser op basis van de ontvangen CSP-header.

Content Security Policy generator

De CSP-header wordt gegenereerd door de server van de website en wordt naar de browser van de gebruiker gestuurd bij elke HTTP-reactie. Het definieert de beleidsregels voor het laden van bronnen, zoals scripts, stijlbladen, afbeeldingen, enz., en vertelt de browser welke bronnen het mag laden en uitvoeren op de webpagina.

Deze beleidsregels zijn echter configureerbaar en kunnen we aanpassen aan de specifieke behoeften en vereisten van een website. Ze zijn dynamisch te genereren op basis van verschillende factoren, zoals de bron van de inhoud, de beveiligingsbehoeften van de site en meer.

Kortom, terwijl de CSP-header technisch gezien niet “harde code” is in de traditionele zin van het woord, omdat deze dynamisch wordt gegenereerd door de server, is het een essentieel onderdeel van de beveiligingsconfiguratie van een website.

We moeten dat beleid eerst uitwerken en met elkaar bespreken (in 5 stappen)

Voordat we een Content Security Policy implementeren, is het essentieel om het beleid zorgvuldig uit te werken en te bespreken. Dit proces omvat typisch de volgende stappen:

1. Beleidsdefinitie

Identificeer de specifieke behoeften en vereisten van de website op het gebied van beveiliging. Dit omvat het bepalen van welke bronnen moeten zijn toegestaan en welke we willen blokkeren. Bijvoorbeeld, welke domeinen zijn veilig om scripts van te laden? Welke bronnen mogen gebruikmaken van inline scripts en stijlen? Welke acties moeten we toestaan, zoals het gebruik van formulieren of het insluiten van frames?

2. Beleidsbespreking

Bespreek het voorgestelde beleid met alle relevante belanghebbenden, waaronder ontwikkelaars, beveiligingsanalisten en beheerders. Het is belangrijk om eventuele zorgen of vereisten van alle partijen te begrijpen en in overweging te nemen.

3. Testen en valideren

Voor de implementatie van het beleid in een productieomgeving, is het cruciaal om dit beleid grondig te testen en te valideren in een testomgeving. Dit helpt bij het identificeren van mogelijke problemen of conflicten met de bestaande functionaliteit van de website.

4. Iteratieve aanpassing

Na het testen kunnen er aanpassingen nodig zijn aan het beleid op basis van de bevindingen en feedback van de testfase. Dit kan een iteratief proces zijn waarbij we het beleid meerdere keren aanpassen en opnieuw testen totdat het voldoet aan de beveiligingsbehoeften van de website zonder de functionaliteit te schaden.

5. Implementatie in productie

Zodra het beleid is gevalideerd en goedgekeurd, kunnen we het implementeren in de productieomgeving van de website. Het is belangrijk om tijdens en na de implementatie de prestaties en beveiliging van de website te blijven monitoren en eventuele problemen snel aan te pakken.

Door deze stappen te volgen, kunnen we een effectieve en goed doordachte CSP ontwikkelen en implementeren die de beveiliging van de website verbetert zonder de gebruikerservaring te beïnvloeden.

Voorbeeld van een CSP

Hier is een voorbeeld van een uitgebreide Content Security Policy (CSP) HTTP-header die verschillende bronnen toestaat en beperkingen oplegt om de beveiliging van een website te verbeteren:

Content Security Policy:

• default-src ‘self’;
• script-src ‘self’ https://cdn.example.com https://ajax.googleapis.com;
• style-src ‘self’ https://fonts.googleapis.com;
• img-src ‘self’ https://cdn.example.com data:;
• font-src ‘self’ https://fonts.gstatic.com;
• frame-src https://www.youtube.com;
• object-src ‘none’;
• base-uri ‘self’;
• form-action ‘self’;
• frame-ancestors ‘none’;
• upgrade-insecure-requests;

In dit voorbeeld:

default-src ‘self’;: Dit geeft aan dat de standaardbron voor alle soorten bronnen (scripts, stijlen, afbeeldingen, enz.) de huidige domein is.

script-src ‘self’ https://cdn.example.com https://ajax.googleapis.com;: Hiermee wordt aangegeven dat scripts mogen worden geladen vanaf de huidige domein, evenals vanaf https://cdn.example.com en https://ajax.googleapis.com.

style-src ‘self’ https://fonts.googleapis.com;: Hiermee wordt aangegeven dat stijlbladen mogen worden geladen vanaf de huidige domein en vanaf https://fonts.googleapis.com.

img-src ‘self’ https://cdn.example.com data:;: Dit staat afbeeldingen toe vanaf de huidige domein, van https://cdn.example.com en inline data-URL’s.

font-src ‘self’ https://fonts.gstatic.com;: Dit geeft aan dat lettertypen mogen worden geladen vanaf de huidige domein en vanaf https://fonts.gstatic.com.

frame-src https://www.youtube.com;: Dit geeft aan dat frames alleen geladen mogen worden vanaf https://www.youtube.com.

object-src ‘none’;: Dit staat niet toe dat objecten (zoals Flash) worden ingesloten vanaf externe bronnen.

base-uri ‘self’;: Hiermee geven we aan dat alleen relatieve URL’s zijn toegestaan als basis-URI.

form-action ‘self’;: Dit staat alleen formulieren toe die naar de huidige domein zijn ingediend.

frame-ancestors ‘none’;: Dit staat niet toe dat de pagina wordt ingesloten in een frame.

upgrade-insecure-requests;: Hiermee geven we aan dat browsers HTTP-verzoeken moeten upgraden naar HTTPS.

Dit is slechts een voorbeeld. De exacte configuratie van een CSP kan variëren, afhankelijk van de specifieke behoeften en vereisten van een website. Het is echter belangrijk om de CSP zorgvuldig te configureren en te testen om ervoor te zorgen dat deze de beoogde beveiligingsdoelstellingen bereikt zonder de functionaliteit van de site te belemmeren.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.