Waarom Report-Only zich onderscheidt van Enforced in Content Security Policy

By Mirko Peters · 2026-04-23

Als web security echt belangrijk voor je is, dan is het verschil tussen de modi ‘report-only’ en ‘enforced’ in Content Security Policy (CSP) geen detail—het is het hele verhaal. Report-only laat je zien wat je beleid zou blokkeren zonder daadwerkelijk iets te stoppen, waardoor je website een soort testomgeving voor beveiliging wordt. Enforced daarentegen speelt geen spelletjes: het blokkeert alles

Automatically translated with AI from the original post. Read the English original

Cover: Fix Conditional Access Loopholes in Microsoft 365

Dit artikel legt uit waarom deze modi belangrijk zijn, wat ze doen voor de ervaring van browser en gebruiker, en hoe je van eenvoudige monitoring naar echte bescherming gaat. Het is specifiek bedoeld voor security professionals en developers met een Microsoft-omgeving die hun CSP-configuratie goed willen neerzetten. We behandelen definities, praktische technieken en best practices voor een veilige uitrol en slimme compliance.

CSP-modi en hun impact begrijpen

Voordat je CSP-headers gaat uitdelen, moet je de twee belangrijkste CSP-modi begrijpen: report-only en enforced. Deze modi zijn meer dan alleen instellingen; ze bepalen hoe moderne browsers je webapplicatie beschermen (of alleen observeren) binnen de beveiligingsgrenzen. Wat je kiest, heeft direct invloed op het risiconiveau van je site, de controleerbaarheid en hoe soepel je uitrol verloopt, zeker in grote Microsoft-omgevingen of multi-cloud-opstellingen.

CSP-modi zijn ontworpen om webteams flexibiliteit te geven. Report-only is het zachte instapmoment: je bewaakt op problemen zonder het risico dat je per ongeluk iets voor gebruikers kapotmaakt. Het ondersteunt risicoanalyses, helpt bij het opsporen van hiaten in het beleid en kan verouderde code of onverwacht gedrag van externe partijen blootleggen, terwijl je applicatie volledig operationeel blijft.

Enforced is de hoofdact: het zorgt ervoor dat de browser je instructies daadwerkelijk uitvoert. Als content niet aan je beleid voldoet, wordt die geblokkeerd. Dat verkleint direct het aanvalsoppervlak voor zaken als cross-site scripting of kwaadaardige scripts van derden. Maar het betekent ook dat fouten of onvolledige beleidsregels je applicatie kunnen verstoren als je niet zorgvuldig test en invoert.

Het idee achter de twee CSP-modi is eenvoudig: laat developers en securityteams hun regels in de praktijk verfijnen voordat ze de knop omzetten. Zie het als zijwieltjes voor de beveiliging van je applicatie, maar dan met een finish waarbij je overgaat naar volledige handhaving. Hierna gaan we precies in op hoe report-only je die praktijkfeedback geeft en wat er verandert zodra enforcement in beeld komt.

Hoe Content-Security-Policy-Report-Only werkt voor het rapporteren van overtredingen

Report-only is de manier van CSP om vanaf de tribune mee te kijken voordat je het veld op stapt. Wanneer je de HTTP-header Content-Security-Policy-Report-Only gebruikt, geef je de browser de opdracht om te ‘kijken naar overtredingen, maar niets te blokkeren—alleen te rapporteren’. Zo krijg je een stroom van overtredingsrapporten naar het endpoint dat je opgeeft, met een volledig overzicht van wat geblokkeerd zou worden als het beleid werd afgedwongen.

Browsers sturen deze overtredingsrapporten (vaak als JSON-payloads) zodra een resource je CSP-regels overtreedt. Als een pagina bijvoorbeeld een script probeert te laden van een niet-goedgekeurde bron, wordt in report-only-modus geen enkel script geblokkeerd. Je krijgt wel een melding met details zoals de betrokken URL, welke directive is overtreden en soms een voorbeeld van de verdachte code.

Deze modus is goud waard voor risicoanalyses en veilig testen. Je kunt nieuwe regels uitrollen over een hele reeks webapps, zien wat er wordt geactiveerd en het beleid bijstellen op basis van echte data in plaats van alleen op goede gissingen. Als je legacy-systemen draait of werkprocessen hebt waar veel van afhangt, hoef je geen site-storingen of supportmeldingen te riskeren door te snel te gaan.

Report-only ondersteunt ook gefaseerde uitrol. Begin open, zie wat er moet worden aangepast en werk stap voor stap naar strengere beveiliging toe. Zo ontdekken teams problemen met scripts van derden, CDN-content of geobfusceerde JavaScript die anders pas verborgen blijven tot enforcement een grote storing veroorzaakt. Bovendien is het een compliance-voordeel: je hebt bewijs dat je actief monitort, wat kan helpen bij audits wanneer je organisatie moet aantonen dat ze zorgvuldig handelt.

Hoe Enforced-modus de beveiliging verhoogt

Afdwingmodus is de fase waarin je CSP-beleid geen suggestie meer is, maar een regel. Wanneer je de Content-Security-Policy-header gebruikt, blokkeren browsers daadwerkelijk alle inhoud die niet aan je richtlijnen voldoet. Geen waarschuwingen, gewoon ingrijpen.

Deze modus versterkt je webapp aanzienlijk tegen aanvallen zoals XSS en ongeautoriseerde script-injectie. Maar wees voorzichtig: als je beleid nog niet productieklaar is, kun je per ongeluk noodzakelijke resources blokkeren en de werking van je site verstoren. Eerst testen in de rapportagemodus is dan ook de slimme keuze. Afdwingmodus is uiteindelijk wat theoretisch beleid omzet in praktische bescherming, en daarmee de gouden standaard voor sterke webbeveiliging.

Rapportage implementeren met report-uri- en report-to-eindpunten

Met het instellen van rapportage krijgt je CSP-beleid echte tanden, en ook een paar extra ogen. Met CSP kun je een of meer eindpunten opgeven (via report-uri of report-to) waarnaar browsers overtredingsrapporten moeten sturen. Wanneer er een overtreding optreedt, verpakt de browser details zoals welke resource is geblokkeerd en welke beleidsregel is gefaald in een netjes JSON- of HTTP POST-bericht, en stuurt dat naar je eindpunt.

De report-uri-richtlijn is de verouderde methode: je geeft een URL op en browsers sturen rapporten rechtstreeks daarheen. Voor moderne flexibiliteit en uitgebreidere rapportage is report-to de nieuwere en robuustere optie, zeker nu browsers steeds beter ondersteuning bieden voor de Reporting API. report-to werkt met een benoemde groep die verschillende soorten rapporten kan verwerken en biedt betere controle over filtering.

Bij het configureren van deze eindpunten wil je ze beveiligen: denk aan HTTPS, toegangsbeheer en monitoring op onverwachte pieken, want die kunnen wijzen op een aanval of een kapot beleid. En vergeet privacy niet: rapporten kunnen URL's of zelfs fragmenten van het verdachte script bevatten. Je moet dus gevoelige informatie kunnen verwijderen voordat je rapporten opslaat of deelt, rekening houdend met regelgeving zoals de AVG (GDPR) en de CCPA.

De echte kracht zit in zichtbaarheid. Met goed geconfigureerde rapportage krijg je een live overzicht van waar je beleid overtredingen vangt, zodat je kunt bijsturen, afstellen en uiteindelijk zonder verrassingen veilig kunt overgaan naar afdwinging. Dit niveau van monitoring is essentieel, of je nu één app beheert of een uitgebreide Microsoft 365-omgeving.

CSP-syntaxis en richtlijnen begrijpen voor effectief beleidsontwerp

Een solide CSP-header schrijven is geen rocket science, maar het vraagt wel om oog voor detail, zeker wanneer je complexe apps en Microsoft-cloudintegraties combineert. In de basis is een CSP-beleid een gestructureerde lijst met richtlijnen, waarbij elke richtlijn de browser vertelt wat wel en niet is toegestaan. Je stuurt deze beleidsregels mee via HTTP-headers, meestal als Content-Security-Policy of Content-Security-Policy-Report-Only, en ze worden opgemaakt als strings met regels die door puntkomma's zijn gescheiden.

Het hart van je beleid bestaat uit kernrichtlijnen zoals default-src, script-src en img-src. default-src is je terugvaloptie: als een bepaald type inhoud geen eigen regel heeft, kijkt de browser naar deze. script-src en img-src richten zich op respectievelijk scripts en afbeeldingen, zodat je strak kunt bepalen welke bronnen vertrouwd worden (denk aan je eigen domeinen, vertrouwde CDN's en misschien een Microsoft Azure-blobopslag of twee).

Syntaxis doet ertoe. Elke richtlijn somt de toegestane waarden op: URL's, schema's zoals ‘https:’ of trefwoorden zoals ‘self’. Als je inline scripts toestaat (soms nodig voor legacy-code), heb je mogelijk ‘unsafe-inline’ nodig. Wees hier voorzichtig mee, want dat verzwakt je bescherming, tenzij je script-hashes of nonces gebruikt voor extra validatie.

Let voor Microsoft-professionals op hoe cloudservices afhankelijkheden injecteren. Complexe enterprise-apps laden assets vaak dynamisch, gebruiken service workers of integreren externe providers. Je beleid moet een balans vinden tussen strak (voor de beveiliging) en flexibel genoeg om de app te laten werken. Zorg vooraf dat de basis klopt, dan verloopt het testen daarna een stuk soepeler.

Best practices voor de overstap van rapportagemodus naar afdwingmodus

De slimste aanpak met CSP is beginnen in de rapportagemodus, gegevens verzamelen en pas daarna afdwinging inschakelen. Behandel CSP-implementatie niet als een eenmalige checklist. Zie het liever als een gefaseerd project, waarin je beleid monitort, bijstelt en geleidelijk aanscherpt, zodat je geen functionaliteit breekt voor eindgebruikers of bedrijfskritische processen.

Begin met een brede maar verstandige beleidsregel in de modus alleen-rapporteren. Verzamel de overtredingsmeldingen en bundel ze bij voorkeur in dashboards of analysetools, zodat je de terugkerende overtreders snel ziet. Zo filter je de ruis eruit, sorteer je de valse positieven weg en richt je je op de echte risico's. Als je veel routinematige of overbodige meldingen ziet (wat heel gebruikelijk is), verfijn dan je log-analyse of schrijf filters in een script, bijvoorbeeld op user agent of resourcetype.

Zodra het aantal overtredingen daalt en de meeste problemen zijn opgelost, begin je stapsgewijs met het afdwingen van de regels, terwijl je blijft letten op nieuwe storingen. Zet eerst de risicovolle maar weinig gebruikte onderdelen om naar afdwingen en houd ze in de gaten. Als dat goed verloopt, breid je uit naar de rest van het project. Documenteer de wijzigingen en vraag gedurende het hele proces feedback aan ontwikkelaars en belanghebbenden, vooral in complexe Microsoft 365- of Azure-apps waar lagen van voorwaardelijke toegang extra haken en ogen hebben. Voor aanverwante strategieën en uitrolplannen is het de moeite waard om deze gids over trust issues bij voorwaardelijke toegang en deze aflevering over identiteitsbeveiliging te bekijken.

Onderschat testen nooit. Gebruik de ontwikkelaarstools van de browser, CSP-statustesters en zelfs geautomatiseerde CI/CD-scans om te controleren of je beleid werkt zoals bedoeld. Het uiteindelijke doel? Een afgeschermde, compliant en robuuste applicatie, beveiligd door een beleid dat in de praktijk is bijgeschaafd en niet op wishful thinking is gebaseerd.

Praktijkvoorbeelden van CSP in de modi alleen-rapporteren en afdwingen

Niets maakt CSP zo concreet als echte voorbeelden. In de modus alleen-rapporteren kun je bijvoorbeeld een header gebruiken zoals: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Deze opzet logt elke overtreding, maar laat je gebruikers ongemoeid, waardoor hij ideaal is om zonder risico in productie te testen.

Vergelijk dat met een afgedwongen beleid: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Nu stopt de browser actief elk script of elke afbeelding die niet aan de regels voldoet, en beschermt hij je gebruikers meteen tegen ongeautoriseerde content.

In de praktijk beginnen organisaties met de modus alleen-rapporteren om te ontdekken welke leveranciers, scripts of zakelijke functies zouden breken onder een strikte afschermingsregel. Een overheidsportaal ontdekt bijvoorbeeld oude scripts of een CDN van een marketinganalysetool die steeds opnieuw overtredingen veroorzaakt. Ze itereren, zetten veilige leveranciers op de witte lijst en dwingen het definitieve beleid vervolgens gefaseerd af om verstoringen tot een minimum te beperken.

Overstappen van alleen-rapporteren naar afdwingen kan verborgen valkuilen blootleggen, vooral bij scripts van derden of dynamische content. Teams krijgen vaak te maken met 'spookovertredingen' die alleen in bepaalde browsers of onder specifieke omstandigheden optreden. Met live data uit de fase van alleen-rapporteren passen ze het beleid aan totdat afdwingen niet alleen veilig is, maar ook stabiel voor iedereen die erbij betrokken is.

Samenvatting van de belangrijkste verschillen tussen de modi alleen-rapporteren en afdwingen

Gedrag: In de modus alleen-rapporteren worden alleen beleidsovertredingen gemeld; er wordt niets geblokkeerd. In de modus afdwingen wordt alles geblokkeerd dat niet aan je CSP-beleid voldoet.
Doel: Met alleen-rapporteren test en stel je beleid af zonder enig risico voor gebruikers. Afdwingen is bedoeld voor echte bescherming, zodat je beveiligingsregels effectief worden.
Impact op gebruikers: Alleen-rapporteren is onzichtbaar; gebruikers merken er niets van. In de modus afdwingen kunnen functies of content breken als je je regels niet vooraf hebt getest.
Toepassingen: Alleen-rapporteren is ideaal voor gefaseerde uitrol, risicoanalyse en controles op compatibiliteit met oudere systemen. Afdwingen is de laatste stap naar robuuste, compliant beveiliging.
Compliance & risico: Alleen-rapporteren helpt bij monitoring en documentatie tijdens audits, terwijl afdwingen overtredingen en beveiligingsincidenten in realtime direct voorkomt.