Waarom report-only zich van enforced onderscheidt in Content Security Policy

By Mirko Peters · 2026-04-23

Als webbeveiliging echt belangrijk voor je is, dan is het verschil tussen de modi ‘report-only’ en ‘enforced’ in Content Security Policy…

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

Als webbeveiliging echt belangrijk voor je is, dan is het verschil tussen de modi ‘report-only’ en ‘enforced’ in Content Security Policy (CSP) geen detail, maar het hele verhaal. In report-only-modus zie je wat je beleid zou blokkeren, zonder dat er iets daadwerkelijk wordt tegengehouden. Zo wordt je website een soort testomgeving voor beveiliging. Enforced-modus speelt daarentegen geen spelletje: alles wat in strijd is met je beleid wordt geblokkeerd, en je site wordt direct afgeschermd.

In dit artikel bekijken we waarom deze modi ertoe doen, wat ze betekenen voor browsers en gebruikers, en hoe je van simpele monitoring naar echte bescherming overstapt. Het is vooral bedoeld voor beveiligingsprofessionals en ontwikkelaars met een Microsoft-omgeving die hun CSP-configuratie goed willen inrichten. We behandelen definities, praktische technieken en best practices voor een veilige uitrol en slimme naleving van regels.

De CSP-modi en hun impact

Voordat je CSP-headers gaat uitrollen, moet je de twee belangrijkste CSP-modi goed begrijpen: report-only en enforced. Dit zijn meer dan instellingen. Ze bepalen hoe moderne browsers je webapplicatie beschermen (of alleen observeren). Je keuze heeft directe invloed op het risiconiveau van je site, de auditmogelijkheden en hoe soepel je uitrol verloopt, zeker in grote Microsoft-omgevingen of multi-cloudopstellingen.

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

Enforced-modus is de echte werkelijkheid: de browser voert je instructies daadwerkelijk uit. Als inhoud niet aan je beleid voldoet, wordt die geblokkeerd. Zo verklein je direct het aanvalsoppervlak voor zaken als cross-site scripting of kwaadaardige scripts van externe partijen. Het betekent wel dat fouten of onvolledige beleidsregels je applicatie kunnen verstoren als je niet zorgvuldig test en invoert.

Het idee achter twee CSP-modi is simpel: laat ontwikkelaars en beveiligingsteams hun regels in de praktijk verfijnen voordat ze de knop omzetten. Zie het als zijdelingse steuntjes voor de beveiliging van je applicatie, maar dan met een finish waarbij je overstapt naar volledige handhaving. Hierna gaan we in op hoe report-only je 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 letten op overtredingen, maar niets te blokkeren, alleen te rapporteren. Zo krijg je een stroom aan overtredingsrapporten naar het eindpunt dat je hebt opgegeven, met een volledig overzicht van wat er geblokkeerd zou worden als het beleid wel werd afgedwongen.

Browsers sturen deze overtredingsrapporten (vaak als JSON-payloads) zodra een bron je CSP-regels schendt. Als een pagina bijvoorbeeld een script probeert te laden van een niet-goedgekeurde bron, wordt dat script in report-only-modus niet geblokkeerd. Je krijgt wel een melding met details, zoals de betreffende URL, de overtreden richtlijn 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 gissingen. Draai je verouderde systemen of kritieke bedrijfsprocessen, dan ga je geen risico lopen op storingen of supporttickets door te snel te werk te gaan.

Report-only ondersteunt ook geleidelijke uitrol. Begin ruim, zie wat moet worden aangepast en werk stap voor stap naar strengere beveiliging toe. Teams ontdekken hiermee problemen met scripts van externe partijen, CDN-inhoud of geobfusceerde JavaScript, die anders pas verborgen blijven totdat enforcement een gigantische storing veroorzaakt. Bovendien scoor je punten op het gebied van naleving: je kunt aantonen dat je actief monitort, wat handig is bij audits wanneer je organisatie moet laten zien dat ze zorgvuldig handelt.

Hoe enforced-modus de beveiliging verhoogt

Enforced mode 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 content die niet overeenkomt met je richtlijnen. Geen waarschuwingen, maar gewoon ingrijpen.

Deze modus maakt je webapp een stuk weerbaarder 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 functionaliteit van je site verstoren. Eerst testen in de report-only-modus is daarom de slimste aanpak. Enforced mode maakt van theoretisch beleid uiteindelijk praktische bescherming, en daarmee is het dé gouden standaard voor sterke websecurity.

Rapportage implementeren met Report-URI- en Report-To-endpoints

Met rapportage geef je je CSP-beleid echte tanden, en ook een paar ogen. Met CSP kun je een of meer endpoints opgeven (via report-uri of report-to) waar browsers overtredingsrapporten naartoe moeten sturen. Bij een overtreding verpakt de browser details zoals welke resource is geblokkeerd en welk beleid is overtreden in een overzichtelijk JSON- of HTTP POST-bericht, en stuurt dat naar je endpoint.

De report-uri-richtlijn is de oude methode: je geeft een URL op en browsers sturen de rapporten daar rechtstreeks naartoe. Voor moderne flexibiliteit en uitgebreidere rapportage is report-to de nieuwere, robuustere optie, zeker nu browsers de Reporting API steeds beter ondersteunen. report-to werkt met een benoemde groep die verschillende soorten rapporten kan verwerken en biedt betere filtermogelijkheden.

Bij het configureren van deze endpoints wil je ze beveiligen: denk aan HTTPS, toegangsbeheer en monitoring op onverwachte pieken, want die kunnen wijzen op een aanval of een kapot beleid. Vergeet ook privacy niet: rapporten kunnen URL's of zelfs fragmenten van het verdachte script bevatten. Je moet daarom gevoelige informatie kunnen verwijderen voordat je rapporten opslaat of deelt, met oog voor regelgeving zoals de AVG (GDPR) en 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 veilig kunt overgaan op handhaving zonder verrassingen. Dit niveau van monitoring is essentieel, of je nu één app beheert of een uitgebreide Microsoft 365-omgeving.

CSP-syntaxis en richtlijnen begrijpen voor een effectief beleidsontwerp

Een goede CSP-header schrijven is geen raketwetenschap, maar je moet wel goed opletten, zeker wanneer je complexe apps en Microsoft-cloudintegraties combineert. In de kern is een CSP-beleid een gestructureerde lijst van richtlijnen, waarbij elke richtlijn aangeeft 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, geformuleerd als strings met regels die door puntkomma's worden 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 content geen eigen regel heeft, kijkt de browser naar deze. script-src en img-src richten zich op 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 blob of twee).

Syntaxis doet ertoe. Elke richtlijn somt 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 dit verzwakt je bescherming tenzij je script-hashes of nonces gebruikt voor extra validatie.

Voor Microsoft-professionals is het belangrijk te letten op hoe cloudservices afhankelijkheden injecteren. Complexe enterprise-apps laden middelen vaak dynamisch, gebruiken service workers of integreren externe providers. Je beleid moet een balans vinden tussen strak (voor de beveiliging) en ruim genoeg om de app te laten functioneren. Als je de basis vooraf goed regelt, verloopt het testen later een stuk soepeler.

Best practices voor de overstap van report-only naar enforced mode

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

Begin met een brede maar verstandige policy in alleen-rapportagemodus. Verzamel de overtredingsrapporten en aggregeer ze, bij voorkeur met dashboards of analysetools, zodat je de terugkerende overtreders zichtbaar maakt. Zo filter je de ruis weg, sorteer je de valse positieven eruit en richt je je op de echte risico's. Als je veel routinematige of overbodige rapporten vindt (wat heel gewoon is), stem dan je log-analyse af of schrijf zelfs scriptfilters op basis van user agent of resourcetype.

Zodra het aantal overtredingen daalt en de meeste problemen zijn opgelost, begin je geleidelijk met het afdwingen van de regels, terwijl je blijft letten op nieuwe storingen. Zet eerst de gevoelige secties met weinig verkeer in de afdwingende modus en monitor die. Als alles soepel verloopt, breid je uit naar de rest van het project. Documenteer de wijzigingen en vraag gedurende het hele proces feedback aan ontwikkelaars en stakeholders, zeker in complexe Microsoft 365- of Azure-apps waar de lagen van voorwaardelijke toegang er extra uitdagingen bij brengen. Voor aanvullende strategieën en uitrolplannen loont het de moeite om deze gids over vertrouwensproblemen 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 policies werken zoals verwacht. Het einddoel? Een afgesloten, compliant en veerkrachtige applicatie, beveiligd door een policy die in de praktijk is aangescherpt en niet op wensdenken berust.

Praktijkvoorbeelden van CSP in alleen-rapportage- en afdwingende modus

Niets maakt CSP zo duidelijk als echte voorbeelden. In de alleen-rapportagemodus gebruik je bijvoorbeeld een header 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. Dat maakt hem ideaal om zonder risico in productie te testen.

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

In de praktijk beginnen organisaties met de alleen-rapportagemodus om te ontdekken welke leveranciers, scripts of zakelijke functies zouden breken onder een strikte afscherming. Zo maakt een overheidsportaal bijvoorbeeld misschien duidelijk dat oude scripts of een CDN voor marketinganalyse steeds overtredingen veroorzaken. Ze passen de policy stap voor stap aan, zetten veilige providers op de witte lijst en dwingen de afgeronde policy vervolgens gefaseerd af om verstoringen tot een minimum te beperken.

Overstappen van alleen-rapportage 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 rapportagefase passen ze de policy aan totdat afdwingen niet alleen veilig is, maar ook stabiel voor iedereen die erbij betrokken is.

Belangrijkste verschillen tussen de alleen-rapportage- en de afdwingende modus

• Gedrag: In de alleen-rapportagemodus worden overtredingen van de policy alleen gerapporteerd; er wordt niets geblokkeerd. In de afdwingende modus wordt alles geblokkeerd dat niet aan je CSP-policy voldoet.
• Doel: Met alleen-rapportage test en stem je policies af zonder risico voor gebruikers. De afdwingende modus is er voor echte bescherming, zodat je beveiligingsregels werkelijk gelden.
• Impact op gebruikers: Alleen-rapportage is onzichtbaar; gebruikers merken er niets van. In de afdwingende modus kunnen functies of content breken als je je regels niet vooraf hebt getest.
• Gebruikssituaties: Alleen-rapportage is ideaal voor geleidelijke uitrol, risicoanalyse en compatibiliteitscontroles met oudere systemen. De afdwingende modus is de laatste stap naar robuuste, compliant beveiliging.
• Compliance & risico: Alleen-rapportage helpt bij monitoring en documentatie tijdens audits, terwijl de afdwingende modus beveiligingsinbreuken in realtime direct voorkomt.