A restrictive Content Security Policy can protect a site and still break a legitimate workflow if the policy was assembled without testing. Report-only mode provides a way to observe violations while preparing the policy for enforcement.
MDN’s CSP guide explains that the Content-Security-Policy-Report-Only response header generates reports without enforcing that policy. An existing enforced policy remains in effect if both headers are present. Report-only is therefore a testing mechanism, not proof that the proposed restrictions already protect the page.
Test the routes that carry the work
Build a short workflow list: sign-in, form submission, payment handoff where applicable, uploads, embedded content and the administrative interface. Test the relevant roles and browsers. A successful homepage load tells you little about a script used only after a user submits a form.
For example, a proposed policy may produce a report when a legitimate preview component loads. Investigate why the resource is needed, who controls it and whether the implementation can be improved. Do not immediately add every reported origin to an allowlist.
Make the reports usable and private
Configure the reporting mechanism according to current browser and platform documentation. Limit who can read collected reports and review whether URLs or other fields may contain sensitive information. Define retention and handling before collecting production traffic.
Group reports by route, directive and resource so repeated noise does not hide a genuine issue. Browser extensions and unusual client conditions can contribute reports that need interpretation. An empty dashboard can also mean reporting was misconfigured, so generate a controlled test violation in an authorised test environment.
MDN notes that report-only policies cannot be delivered through a meta element. Verify the actual HTTP response headers, not just the intended server configuration.
Once essential workflows pass and remaining findings are understood, plan a monitored enforcement rollout with a rollback route. Keep testing as the site changes. A useful CSP process connects the policy to working application behaviour instead of treating a header’s presence as the final result.