Maak je website veiliger met een Content-Security-Policy (CSP)

We ontvangen steeds vaker vragen van onze klanten over het (veilig) configureren van een Content Security Policy (CSP). Daarom hebben we besloten om onze kennis over het instellen van een CSP te delen via deze blogpost. De CSP geeft de browser instructies over vanaf welke locatie welke resources ingeladen mogen worden. Daarnaast geeft het instructies hoe deze binnen de applicatie gebruikt mogen worden. Een goed ingestelde CSP kan fijnmazige instructies bevatten over wat er wel en niet uitgevoerd mag worden en kan daardoor kwetsbaarheden zoals Cross-Site Scripting (XSS) afvangen en voorkomen.

De achtergrond

De CSP-standaard heette oorspronkelijk Content Restrictions en was in 2004 door Robert Hansen (Mozilla) in het leven geroepen. Deze aankondiging werd op de website ha.ckres.org gedaan en is via de Wayback Machine terug te vinden. De header werd als eerst ondersteund door Mozilla Firefox 4 en andere browsers volgden al snel. In 2012 werd de CSP als W3C-kanditaat aanbevolen en dit bevorderde de adoptie van deze security header. Later volgden level 2 (2014) en level 3 (2015) van de CSP en deze worden op dit moment door de meeste webbrowsers ondersteund.

De CSP-header heeft in het verleden meerdere alternatieven en implementaties gekend. De volgende headernamen zijn bij voorgaande implementaties gebruikt:

• X-WebKit-CSP: experimentele header geïntroduceerd in 2011 door Google Chrome, Safari en andere WebKit-gebaseerde webbrowsers.
• X-Content-Security-Policy: experimentele header geïntroduceerd in op Gecko 2 gebaseerde browsers zoals Mozilla Firefox.

De huidige CSP implementatie bestaat uit de header Content-Security-Policy gevolgd door applicatieafhankelijke waarden en attributen. Een applicatie kan bijvoorbeeld de onderstaande CSP-header meesturen:

default-src 'self'; object-src 'none'; child-src 'self'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content

Waarom een Content Security Policy (CSP)?

Het belangrijkste voordeel van een CSP is het voorkomen van Clickjacking en injectie-kwetsbaarheden zoals Cross-Site Scripting (XSS). Met een strak afgestelde CSP kan een kwaadwillende die een XSS-kwetsbaarheid vindt, deze niet uitbuiten omdat de webbrowser van het slachtoffer de uitvoer van scriptcode blokkeert.

Daarnaast wordt een (strak afgestelde) CSP steeds vaker een verplichting vanuit audits. Tijdens een DigiD pentest wordt bijvoorbeeld gecontroleerd of binnen de CSP geen onveilige functies zoals unsafe-eval en unsafe-inline gebruikt worden.

Hoe een Content Security Policy (CSP) instellen?

Het instellen van een strak afgestelde CSP is applicatieafhankelijk, er bestaat geen one-site-fits-all CSP. Een CSP is opgebouwd uit meerdere attributen en waarden en deze verschillen per applicatie. Onderstaand volgt er per attribuut een korte beschrijving over welke instructies en gedragingen het de webbrowser kan opleggen:

• child-src: controleert de context van genestelde bronnen zoals de -tag.
• connect-src: biedt controle over communicatie zoals fetch, XHR, eventsource en websockets.
• font-src: bepaalt vanuit welke URL’s lettertypen (fonts)  ingeladen mogen worden.
• img-src: bepaalt vanuit welke URL’s afbeeldingen ingeladen mogen worden.
• manifest-src: bepaalt vanuit welke URL’s het manifest van de applicatie ingeladen mag worden.
• media-src: bepaalt vanuit welke URL’s mediabronnen zoals audio en video ingeladen mag worden.
• prefetch-src: bepaalt de URL’s waarvandaan bronnen kunnen worden geprefetched.
• object-src: bepaalt vanuit welke URL’s plugins ingeladen mogen worden.
• script-src: bepaalt de locaties waarvandaan scriptcode zoals JavaScript uitgevoerd mag worden.
• style-src: bepaalt waarvandaan stijlen toegepast mogen worden. Dit betreft -elementen, @import-regels en de Link-header.
• default-src: dit fungeert als fallbackmechanisme voor de andere CSP-attributen.
• frame-ancestors: bepaalt welke websites de applicatie mogen insluiten (embedden). Hier kan gedacht worden aan de