Defaults.Exposed › Oplossingen › Content-Security-Policy (CSP)

Hoe je Content-Security-Policy (CSP) oplost

Een Content Security Policy is een veiligheidsregel die uw website aan de browser van elke bezoeker overhandigt, met precies welke code mag draaien. Zonder zo'n regel zal de browser, als er ooit iets kwaadaardigs op een pagina belandt — via een reactieveld, een gehackte plug-in, of een extern script — die vrijelijk uitvoeren, inclusief code die stilletjes de kaartnummers en wachtwoorden van uw klanten afroomt terwijl ze typen, met het hangslot nog steeds in beeld.

De kern voor je bedrijf: Als met uw site ooit wordt geknoeid, kan kwaadaardige code de betaalkaart- en logingegevens van uw klanten regelrecht van uw eigen afrekenpagina lezen terwijl alles er volkomen normaal uitziet — en u achterlaten met terugboekingen, fraudeclaims, een meldingsplichtige datalek, en een gefaalde controle die de beveiligingsafdelingen van grotere klanten gebruiken om een deal stil te leggen of te beëindigen.

Wat dit je kan kosten

Verborgen code glipt op een van uw pagina's en kopieert stilletjes elk kaartnummer en wachtwoord dat uw klanten bij het afrekenen invoeren, en stuurt het naar een aanvaller terwijl uw site er volkomen normaal uitziet — u komt er pas achter wanneer de fraudeklachten binnenkomen.
Een oplichter plaatst een vals «betaal hier»-formulier op uw echte website dat betalingen naar zijn eigen rekening vangt; klanten denken dat ze u hebben betaald, geven u de schuld wanneer de goederen nooit komen, en eisen hun geld terug.
De beveiligingsafdeling van een grotere klant scant uw site, ziet dat deze basisbescherming uitstaat, en markeert het — wat u het contract laat stilleggen of verliezen tot u kunt bewijzen dat het is opgelost.
Een inbreuk herleid tot een ontbrekende standaardvoorzorgsmaatregel wordt een meldingsplichtig incident: vragen van de toezichthouder, klantmeldingen, en een reputatieklap die veel meer kost dan de gratis oplossing.

Waarom het ertoe doet. Het hangslot bewijst dat de verbinding met uw site privé is, maar het doet niets om te beheersen welke code draait zodra een bezoeker op de pagina is. Een Content Security Policy is de voorzorgsmaatregel die dat wél doet — het vertelt browsers elk script te negeren dat niet van een door u vertrouwde bron kwam, zodat een enkel gemanipuleerd veld, advertentie of plug-in niet kan worden veranderd in een werktuig om het geld en de gegevens van uw klanten te stelen. Het is een beoordeelde controle op uw scorekaart, echte punten waard, en een van de eerste dingen waar een professionele beveiligingsbeoordeling naar kijkt.

Wat dit is, in gewone taal

Wanneer iemand uw website bezoekt, downloadt hun browser uw pagina en draait wat voor code er ook op staat — de scripts die menu’s laten uitklappen, knoppen laten werken, betaalformulieren laten verzenden, enzovoort. Standaard vertrouwt de browser het allemaal. Hij heeft geen manier om te weten welke code echt van u is en welke door iemand anders is binnengeslopen.

Een Content Security Policy (vaak afgekort tot CSP) is een korte lijst regels die uw website aan elke pagina hecht, en de browser vertelt: «draai alleen code van deze bronnen die ik heb goedgekeurd, en weiger al het andere». Het is het verschil tussen een nachtclub die iedereen binnenlaat en een met een gastenlijst bij de deur.

De reden dat dit zo belangrijk is, is dat er voortdurend met websites wordt geknoeid — niet altijd door uw server te hacken, maar via de achterdeuren die de meeste sites openlaten: een reactieveld, een zoekvak, een verouderde plug-in, een extern script voor advertenties of analytics, of een chatwidget. Als een aanvaller ook maar één regel van zijn eigen code op een van uw pagina’s krijgt, draait de browser die alsof het de uwe was. Vanaf daar kan die alles lezen wat uw klanten typen — kaartnummers, wachtwoorden, adressen — en het stilletjes elders heen sturen. Een Content Security Policy sluit die deur door te weigeren iets te draaien van een bron die u niet hebt goedgekeurd.

Wat dit u kan kosten

Dit is niet abstract. De aanval die een Content Security Policy voorkomt — code geïnjecteerd in een pagina die gegevens steelt van uw eigen klanten — zit achter enkele van de grootste kaartskim-inbreuken ooit. Zo verloopt het doorgaans voor een normaal bedrijf:

De onzichtbare afreken-skimmer. Een aanvaller glipt een paar regels code op uw afrekenpagina via een kwetsbare plug-in of een gecompromitteerd extern script. Elk kaartnummer, elke naam en CVV die uw klanten typen wordt in realtime gekopieerd en naar de aanvaller gestuurd. Uw site ziet er perfect uit en werkt perfect; het hangslot is er. U ontdekt het weken later wanneer uw betaalprovider belt over een cluster fraudemeldingen die allemaal terugleiden naar uw winkel. Nu staat u voor terugboekingen, een gedwongen beveiligingsaudit, mogelijk verlies van kaartverwerkingsrechten, en een inbreuk die u wettelijk verplicht kunt zijn te melden.
Het valse betaalformulier. Een oplichter injecteert een overtuigend «betaal hier»-vak op uw echte website. Klanten voeren hun gegevens in vertrouwend op uw merk; het geld en de gegevens gaan naar de aanvaller. De klanten geven u de schuld — en niet ten onrechte, want het gebeurde op uw site.
Het verloren contract. De beveiligingsafdeling van een grotere prospect doet een geautomatiseerde scan van uw site als onderdeel van leveranciers-due-diligence. Een ontbrekende Content Security Policy verschijnt meteen als een gat van hoge ernst. Voor een inkoop- of beveiligingsbeoordelaar leest die ene ontbrekende voorzorgsmaatregel als «deze leverancier doet de basis niet» — en de deal stokt terwijl ze om herstel vragen, of gaat stilletjes naar een concurrent die slaagde.
De meldingsplichtige inbreuk. Wanneer een datalek wordt herleid tot een ontbrekende, standaard, gratis voorzorgsmaatregel, houdt het op pech te zijn en begint het op nalatigheid te lijken. Dat verandert de vragen van de toezichthouder, de meldingsplicht aan klanten, en de kosten — zowel de boete als de reputatieschade, die lang na het sluiten van het incident blijft hangen.
De gecompromitteerde advertentie of widget. Veel sites laden code van buitenpartijen — advertentienetwerken, lettertypen, supportchat, analytics. Als ook maar één daarvan wordt gehackt, rijdt de kwaadaardige code regelrecht uw pagina’s binnen. Een Content Security Policy beperkt de schaderadius door alleen de specifieke buitenbronnen toe te staan die u vertrouwt, zodat de inbreuk van één leverancier niet automatisch de uwe wordt.

Wat het eigenlijk is (het detail)

Een Content Security Policy wordt geleverd als één enkele HTTP-responsheader — een regel die uw webserver bij elke pagina meestuurt. De waarde ervan is een set richtlijnen, elk met een soort content en de bronnen die ervoor zijn toegestaan. Bijvoorbeeld:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

In gewone taal zegt dat: laad standaard alleen dingen van mijn eigen site; draai alleen scripts van mijn eigen site; sta geen oude-stijl plug-ins toe; en laat andere sites de mijne niet in een frame inbedden.

Hoe «goed» eruitziet. Onze controle kijkt niet alleen naar de aanwezigheid van de header — die leest het beleid richtlijn voor richtlijn en scoort hoe sterk het daadwerkelijk is, zoals een beveiligingsbeoordelaar zou doen. Een sterk beleid:

Stelt een restrictieve basis in (default-src 'self') en verbreedt die alleen voor de specifieke vertrouwde derde partijen die u echt gebruikt.
Vermijdt de maaslachten. Het gebruikt geen 'unsafe-inline' of 'unsafe-eval' voor scripts, en gebruikt geen wildcard (*) of kale schemabronnen (zoals https:) voor scripts — die heropenen in feite de deur die het beleid moet dichten. Waar inline scripts echt nodig zijn, gebruikt het een nonce of hash zodat alleen uw specifieke goedgekeurde code draait.
Vergrendelt framing met frame-ancestors 'self' (dit blokkeert ook de «bed uw site in om uw klanten te misleiden»-aanval) en schakelt oude plug-ins uit met object-src 'none'.
Is afdwingend, niet report-only. Een Content-Security-Policy-Report-Only-header kijkt alleen; het biedt nul runtime-bescherming. Onze controle geeft het een klein deel van het krediet en noteert het nooit als een pass. U bent pas beschermd zodra het beleid afdwingt.

Een beleid dat bestaat maar leunt op 'unsafe-inline', 'unsafe-eval' of wildcards zal nog steeds slecht scoren — omdat het in de praktijk weinig echte bescherming biedt. Het doel is een strak beleid, niet zomaar een beleid.

Hoe los je het op (gratis, ~1–2 uur)

Geef dit aan uw IT-persoon of wie uw website beheert — de oplossing zelf is volledig gratis. Wij rekenen alleen ooit kosten om te bewaken dat het op zijn plaats blijft en in de loop van de tijd correct blijft; het aanzetten kost niets. De reden dat dit een uur of twee kost in plaats van minuten, is de zorgvuldige proefstap die voorkomt dat het per ongeluk delen van uw eigen site blokkeert.

Begin in report-only-modus — dwing nog niet af. Voeg een Content-Security-Policy-Report-Only-responsheader toe. Dit kijkt en logt wat geblokkeerd zou worden zonder daadwerkelijk iets te blokkeren, zodat de live site blijft werken terwijl u leert waar elke pagina echt van afhangt. (Belangrijk: report-only op zichzelf geeft bezoekers geen bescherming — het is alleen de veilige eerste stap.)
Bouw het beleid op uit wat uw site daadwerkelijk gebruikt. Bekijk de rapporten om elke legitieme bron van scripts, stijlen, lettertypen en afbeeldingen te vinden — uw eigen domein, uw analytics, uw betaalprovider, uw lettertypenhost, uw chatwidget — en som ze op als toegestane bronnen. Een solide startpunt is default-src 'self' plus expliciete vermeldingen voor de vertrouwde derde partijen die u echt gebruikt.
Vermijd de maaslachten die het hele punt tenietdoen. Blijf weg van 'unsafe-inline' en 'unsafe-eval' voor scripts, en vermijd wildcardbronnen zoals * en kale schema’s zoals https: voor scripts — die heropenen precies het gat dat het beleid moet dichten. Waar inline scripts onvermijdelijk zijn, gebruik een nonce of hash zodat alleen uw specifieke goedgekeurde code draait.
Vergrendel framing en plug-ins. Voeg frame-ancestors 'self' toe (dit stopt ook andere sites die de uwe inbedden om uw klanten te misleiden, en het voldoet aan de gerelateerde clickjacking-controle) en object-src 'none' om aanvallen via oude plug-ins te blokkeren.
Schakel over van report-only naar afdwingend. Zodra de rapporten schoon zijn en de site werkt, wijzig de headernaam van Content-Security-Policy-Report-Only naar Content-Security-Policy. Dit is de stap die daadwerkelijk bescherming levert — een report-only-beleid alleen doet dat niet, en zal de controle niet halen.

Waar u de header instelt hangt af van uw platform:
- Cloudflare: Rules → Transform Rules → Modify Response Header → stel Content-Security-Policy in. (U kunt Cloudflare ook gebruiken voor de report-only-proef.)
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config): voeg een aangepaste HTTP-responsheader toe met de naam Content-Security-Policy en het beleid als waarde.
- Google Workspace / Microsoft 365: deze draaien uw e-mail, niet uw openbare website, dus het beleid wordt ingesteld waar uw website daadwerkelijk wordt gehost (Cloudflare of uw webhost hierboven), niet in uw e-mailadminconsole.
Controleer uw domein opnieuw om te bevestigen dat het beleid nu wordt getoond als aangezet en afdwingend, zonder verzwakkende maaslachten.

Veelgemaakte fouten

Stoppen bij report-only. De meest voorkomende fout: een beleid wordt in report-only-modus toegevoegd, iedereen gaat verder, en de site is nooit daadwerkelijk beschermd. Report-only blokkeert niets. U moet overschakelen naar afdwingend.
Grijpen naar 'unsafe-inline' om het «gewoon te laten werken». Wanneer het beleid een legitiem inline script blokkeert, is de snelle oplossing alle inline scripts toe te staan — maar dat heropent precies het gat dat het beleid moest dichten. Gebruik in plaats daarvan een nonce of hash.
Een wildcard gebruiken. Een kale * (of https:) in script-src staat scripts van overal toe, wat betekent dat het beleid vrijwel geen echte bescherming geeft en nog steeds laag zal scoren.
Externe bronnen vergeten. Een strikt beleid afdwingen zonder eerst de legitieme buitendiensten op te sommen die u gebruikt (analytics, lettertypen, betaalwidgets) kan delen van uw eigen site breken — wat precies is waarom de report-only-proefstap bestaat.
Het alleen op de homepage instellen. Het beleid moet elke pagina dekken, vooral afreken-, login- en accountpagina’s — dat zijn degene die het aanvallen waard zijn.
Het behandelen als vervanging voor het hangslot. Een Content Security Policy en HTTPS/HSTS beschermen verschillende dingen. U wilt ze allemaal; de een dekt niet voor de ander.

Veelgestelde vragen

Ik ben niet technisch — kan ik dit zelf regelen?

U hoeft de details niet te begrijpen. Dit is een instelling die wordt toegevoegd door wie uw website of hosting beheert, en op diensten als Cloudflare is het grotendeels begeleid. Geef hun het onderdeel «Hoe los je het op» hieronder. Het is gratis; de ene waarschuwing is dat het zorgvuldig moet worden uitgerold in een alleen-kijken-proef eerst, zodat het niet per ongeluk delen van uw eigen site blokkeert — wat precies is wat de stappen behandelen.

Ik heb al het hangslot en een SSL-certificaat — is mijn site dan niet veilig?

Het hangslot beveiligt de aflevering van uw pagina; het surveilleert niet wat erbinnen draait. Als kwaadaardige code ooit op een pagina belandt — via een gehackte plug-in, een gecompromitteerde advertentie, of een geïnjecteerd veld — zal het hangslot niet voorkomen dat die gegevens steelt. Een Content Security Policy is de laag die beperkt wat überhaupt mag draaien. Ze beschermen verschillende dingen, en u wilt beide.

Kan dit aanzetten mijn site breken?

Dat kan als het in één keer agressief wordt aangezet, omdat het legitieme scripts die u daadwerkelijk gebruikt kan blokkeren. Daarom is de standaardaanpak te beginnen in een «report-only»-proefmodus die kijkt zonder te blokkeren, alles op te lossen wat die markeert, en het pas dan af te dwingen. Op deze manier gedaan is het veilig — en de proefstap is ingebouwd in de oplossing hieronder.

We hebben het al in «report-only»-modus gezet — zijn we gedekt?

Nee, en dit is het meest voorkomende valse gevoel van veiligheid. Report-only-modus kijkt en logt wat geblokkeerd zou worden, maar blokkeert niets — bezoekers krijgen nul echte bescherming. Het is alleen de veilige eerste stap. Onze controle geeft report-only een klein deel van het krediet van een echt beleid en noteert het niet als een pass. U bent pas beschermd zodra u overschakelt naar afdwingende modus.

Beïnvloedt dit onze score, of is het alleen adviserend?

Het beïnvloedt uw score. De Content Security Policy-controle is beoordeeld en tot 25 punten waard in de categorie Webbeveiliging. Een ontbrekend of zwak beleid wordt als hoge ernst gemarkeerd en trekt uw beoordeling omlaag — en het is precies het soort gat waar de beveiligingsvragenlijst van een klant naar vraagt.

Onze ontwikkelaar voegde een beleid toe maar de score is nog steeds laag — waarom?

Een beleid kan bestaan en toch zwak zijn. De meest voorkomende boosdoeners zijn maaslachten zoals «unsafe-inline» en «unsafe-eval» voor scripts, of wildcardbronnen (een kale *), die precies het gat heropenen dat het beleid moet dichten. Onze controle leest het beleid richtlijn voor richtlijn en scoort die zwakheden omlaag — een beleid dat alles toestaat scoort nauwelijks beter dan helemaal geen. De oplossing is de scriptregels aan te scherpen met nonces of hashes in plaats van die maaslachten.