Content security policy: Een overzicht

De kern van elke websitebeveiligingsstrategie zijn HTTP-headers. Deze response-headers zijn verantwoordelijk voor het vertellen van de browser welke acties te ondernemen. Ze reguleren ook de uitwisseling van informatie tussen de gebruiker en de server, en beschermen zo gevoelige gegevens. Een Content Security Policy is een van deze HTTP-headers die je kunt kiezen om op je site te implementeren.

Een CSP bestaat uit verschillende richtlijnen die de browser vertellen hoe zich te gedragen, regulerend welke bronnen geladen kunnen worden. Je kunt bijvoorbeeld specificeren van welk domein scripts en afbeeldingen geladen kunnen worden of inline scripts verbieden.

Dankzij deze functies beschermt je CSP gebruikers tegen schadelijke plug-ins en malware. Het minimaliseert ook de risico's van cross-site scripting. Houd er rekening mee dat je waarschijnlijk met dergelijke risico's te maken krijgt, ongeacht hoe sterk de beveiligingsstrategie van je website is.

De relatie tussen CSP en webtracking

Webtracking en analyses zijn een vitaal onderdeel van de strategie van een bedrijf. Maar het verzamelen van deze gegevens gaat niet zonder risico's. Dit is waar, zelfs als je alleen vertrouwde externe tools zoals Google Analytics gebruikt.

De primaire rol van een CSP is ervoor te zorgen dat de scripts, afbeeldingen en bronnen op een pagina van gebruikers afkomstig zijn van veilige bronnen. Het beleid doet dit door schadelijke activiteiten van externe leveranciers en niet-herkende domeinen te voorkomen. Een CSP kan echter niet onderscheiden tussen de niet-schadelijke code die door Google Tag Manager (GTM) of Google Analytics wordt gebruikt en schadelijke JavaScript. Daarom, als je de activiteiten van je gebruikers wilt blijven volgen, is het essentieel om je CSP te optimaliseren. Je kunt dit doen door een CSP te schrijven die scripts van Google herkent en toestaat.

Moet je het risico nemen en blijven werken met GTM?

Waarom beschouwt je CSP een gezaghebbende en betrouwbare bron (d.w.z. Google) als gelijkwaardig aan een schadelijke script? Het antwoord is dat wat GTM zo nuttig maakt, ook je site kwetsbaarder maakt.  GTM is niets meer dan een container van JavaScript-codeblokken. Dit stelt marketeers en ontwikkelaars in staat om Google- en externe tags te wijzigen, te maken en te vervangen. 

Deze flexibiliteit en gebruiksgemak komen tegen een prijs: iedereen kan een nieuwe "custom tag" toevoegen met minimale supervisie. En als je site geen CSP heeft, kan het gemakkelijk gebruikers toestaan schadelijke afbeeldingen en scripts te laden. Het gebruik van Google Analytics en GTM samen is een krachtige combinatie. Om de twee samen te laten werken, is het de moeite waard om je CSP te optimaliseren.

Efficiënte manieren om je CSP voor GTM te optimaliseren

Bij het optimaliseren van je CSP voor GTM kan het verleidelijk zijn om simpelweg script-src https://analytics.google.com/ en https://tagmanager.google.com/ aan je beleid toe te voegen. Door dit te doen, kun je er misschien voor zorgen dat je GTM werkt, maar je aangepaste JavaScript-variabelen retourneren waarschijnlijk undefined. Dit gebeurt ook bij gebruik van de ‘unsafe-inline tag. 

Een andere oplossing waar velen voor kiezen is het toevoegen van het unsafe-eval argument. Dit zal je GTM inschakelen, maar het zal ook de uitvoering van elk ander script toestaan. Dit zal op zijn beurt je CSP laten stoppen met het beschermen van je site. 

In plaats van de bovenstaande voorbeelden, zou je moeten proberen een hash of een nonce te gebruiken. Hoe dan ook, vergeet niet altijd toegankelijke domeinen aan je bestaande CSP toe te voegen - creëer er geen tweede!

Gebruik een hash om de veiligheid en integriteit van het script te verifiëren

Begin met het controleren of een bepaalde bron betrouwbaar, veilig en gerenommeerd is - zoals Google. Een hash verifieert dat scripts van die bron niet zijn aangepast op weg naar je site. Als de bron oorspronkelijk veilig was en de hash de integriteit waarborgt, is het veilig om inhoud van die bron toe te staan. 

Echter, zelfs kleine wijzigingen zoals het toevoegen van een spatie zorgen ervoor dat de hash het script ongeldig maakt. Misschien ken je dit mechanisme als SubResource Integrity (SRI), een strategie die ontwikkelaars veel gebruiken in populaire scripts zoals jQuery.

Gebruik een nonce voor consistentie en doeltreffendheid

Aangezien GTM ontwikkelaars en marketeers in staat stelt verschillende tags en variabelen te maken, zal het script elke keer anders zijn. In dit geval kunnen hashes omslachtig en ineffectief worden. In plaats daarvan zou je moeten overwegen een nonce te gebruiken, wat staat voor "number-used-once." 

Het enige wat je hoeft te doen is dezelfde nonce aan je CSP en aan je script-tag toe te voegen. Dus, de browser ontvangt instructies dat die inhoud veilig is. Voordat je een nonce implementeert, moet je er rekening mee houden dat de kans onomkeerbaar is.

Samenwerken met je ontwikkelaar

Het verwijderen van het ‘unsafe-inline argument uit je beleid betekent dat geen willekeurige code kan worden uitgevoerd. Hoewel dit betekent dat de site veiliger wordt, kun je moeite hebben om samen te werken met je ontwikkelaars. Het punt is dat zij de neiging kunnen hebben om aangepaste CSP's te gebruiken met andere opties dan een standaardbeleid. 

Bovendien kunnen je ontwikkelaars te maken krijgen met uitdagingen zoals browseronverenigbaarheid. Of het feit dat ze nu cache moeten vermijden. In feite, aangezien elke nonce uniek is, zullen ze een andere pagina aan elke gebruiker moeten serveren.

Fightclub kan je helpen met je CSP-configuratie

Hier bij Fightclub zijn we er trots op veilige, betrouwbare digitale prestaties te leveren. We begrijpen dat data-analyse en -verwerking cruciale componenten zijn van een succesvol bedrijf. Maar we streven er ook naar om de digitale wereld een veiligere plek te maken. Neem vandaag nog contact op om je inhoudsbeveiligingsbeleid te optimaliseren en je web- en app-tracking te stroomlijnen.