A Content Security Policy can reduce which resources a browser is allowed to execute or load, but an untested policy can also break an application's ordinary workflows. Report-only deployment offers a way to observe potential violations before choosing an enforced policy. It is a rehearsal mechanism, not a replacement for enforcement.
The MDN report-only header reference explains how the header monitors violations without enforcing the proposed restrictions. It also describes reporting destinations and unsupported behavior. The useful operational result is a reviewed policy with tested application paths, not simply a dashboard containing a large number of reports.
Define what the candidate policy should protect
Start with the application's intended resource relationships. Identify where scripts, styles, images, frames, and network requests legitimately originate. Include account pages, administrative routes, payment flows, and third-party integrations that may not appear on the public landing page.
Choose an owner for the policy and a review process for changes. Frontend code, templates, proxies, and plugins can all introduce new dependencies. A policy without ownership can drift into either repeated breakage or a collection of overly broad allowances.
Do not treat a copied example as a complete production policy. A directive suitable for a simple static page may be insufficient or incompatible with a complex application. Establish the required behavior before deciding which resource restrictions should become enforceable.
Distinguish observation from blocking
The Content-Security-Policy-Report-Only header lets a browser evaluate a candidate policy and report violations without blocking those actions under that candidate. A suspicious resource continuing to load is therefore expected behavior, not proof that the rehearsal header failed.
An application can also have an existing enforced policy. The report-only policy does not switch off the enforced one or grant permission to resources it blocks. Keep the two configurations distinct in the deployment record and the interpretation of reports.
Explain the current protection accurately to stakeholders. Saying that a strict policy is in report-only mode does not mean the corresponding restrictions protect users today. The decision to move a reviewed policy into enforcement remains a separate change.
Deliver the header through the real serving path
The MDN reference identifies report-only CSP as an HTTP response header and notes that it is not supported through a meta element. Adding policy-looking text to an HTML template is therefore not an equivalent deployment method.
Inspect the response users actually receive through the CDN, reverse proxy, and application route. Different pages or cached responses may carry different headers. A configuration in a source repository is not proof that the browser sees it.
Test the routes and response types relevant to your application. Verify the resulting header after deployment, including redirects or alternate hosts where they affect the workflow. Keep deployment checks close to the actual serving architecture rather than relying solely on a local development page.
Configure a reporting destination deliberately
MDN documents the report-to directive with an endpoint name defined through the Reporting-Endpoints response header. These two pieces must refer to the same intended destination. A candidate policy without functioning report delivery provides much less operational evidence.
An illustrative pairing is:
Reporting-Endpoints: csp-review="https://example.com/csp-reports"
Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-reviewThis is a demonstration of the relationship, not a recommended complete application policy. The endpoint and resource allowances must be designed for the actual site. The example domain does not supply a working collector for your deployment.
Verify browser and collector compatibility
The reference also discusses the older report-uri directive, which is deprecated in favor of report-to, and notes differences in report syntax and browser support. Check the supported browser versions in your own audience before choosing the reporting configuration.
Do not assume that one parser can handle every reporting format identically. Validate the collector against the formats you intend to accept and confirm that representative clients can deliver a known test violation.
Treat missing reports as a diagnostic problem, not evidence that every user journey passed. Client behavior, delivery timing, blocked network paths, and collector failures can all affect visibility. A positive end-to-end test is more convincing than an empty dashboard.
Handle reports as sensitive, untrusted input
A reporting endpoint receives data from clients and should not assume that every submission is authentic or well formed. Apply appropriate request limits, parsing validation, and operational monitoring. Avoid making a public collector an unrestricted storage sink.
Report data can include URLs and other context that deserves privacy review. Restrict access, choose a retention period, and sanitize data before sharing it outside the authorized review group. Do not automatically paste raw reports into public issue trackers.
Separate collection from decision-making. A submitted violation is evidence to examine; it is not an instruction to modify the policy or a verified declaration of compromise. An attacker or a broken client should not be able to widen your allowed sources simply by generating convincing-looking reports.
Review violations by workflow and directive
Group reports into understandable causes: an intended integration missing from the policy, legacy inline behavior, an unexpected resource, or noise introduced by a client's environment. Preserve enough context to connect a report to an application path and deployment version.
Test the relevant workflow directly before expanding an allowance. A repeated report for a third-party origin does not automatically prove the application needs that origin, and a frequently visited route can generate more reports than a critical but rarely used recovery page.
Use the review to reduce unnecessary dependencies where practical. The goal is not to approve every reported source until the dashboard becomes quiet. A policy that permits everything avoids violations by abandoning the restriction you intended to build.
Know what report-only cannot rehearse
The MDN reference says the sandbox directive is ignored in report-only mode. That makes it particularly important not to describe a report-only run as a complete simulation of every possible enforced-policy effect.
Review directive-specific behavior and compatibility for the candidate policy. Some decisions require separate application testing rather than passive collection alone. A lack of reports cannot establish the safety of behavior the rehearsal mode does not evaluate in the intended way.
Remember that CSP is one security layer. It does not replace input validation, authorization, dependency maintenance, or safe handling of user-controlled content. A well-tested header supports those controls; it is not a general certificate that the application is secure.
Move into enforcement with a controlled scope
Once the important workflows have been reviewed, test the candidate policy in a representative environment where its effects can actually block resources. Verify login, editing, uploads, checkout, and recovery paths as applicable to the application.
Use a deployment sequence that limits the impact of mistakes and has a reviewed rollback path. Coordinate proxy and application changes so a cached or duplicated policy does not undermine the test. Record which exact policy version becomes enforced.
Continue collecting useful evidence after enforcement. A new application release can introduce a dependency that the earlier test did not exercise. Monitoring should support diagnosis and ownership rather than encourage a broad emergency exception every time one page changes.
Maintain the policy as application configuration
Keep the policy close to the deployment review process, with clear ownership for the headers and the collector. Recheck it when templates, frontend build systems, plugins, or embedded services change.
Maintain a concise record of legitimate resource origins, tested browser coverage, collector behavior, and exceptions. Explain why each important allowance exists. A policy that can be understood is easier to tighten safely than an unexplained string copied between servers.
Report-only CSP is valuable when it turns a risky header change into an evidence-based rollout. Deliver a real response header, prove reporting works, review violations in context, and test enforcement separately. Observation supplies the information for a protection decision; it does not make that decision on its own.
