Quick answer
When a response contains multiple enforcing Content-Security-Policy policies, a request must satisfy all applicable restrictions. The last header does not simply replace the earlier policy in the browser. Capture the complete delivered policy set, identify the directive blocking the request, and coordinate the origin and CDN owners before changing either configuration.
Inspect the response that actually failed
Open the document request for the affected page and record all CSP response-header values. Some interfaces combine repeated headers into one displayed value, so do not assume one visible line means one policy. Inspect the document for a meta-delivered policy as well. Keep the evidence tied to the same navigation and browser error.
A settings screen is not proof of the final response. A WordPress plugin, server configuration, reverse proxy, or CDN can add or modify headers after another layer has run. Start from what the visitor received, then work backwards to the configuration owners. Redact private URL parameters and unrelated response data before sharing evidence.
Understand the intersection with a small example
Imagine one enforcing policy does not allow a connection to an analytics endpoint while another permits it. The permissive policy does not cancel the restrictive one. This is why adding a second apparently correct header can leave a tracking request blocked even though the new configuration looks generous enough.
Use a request-by-policy table rather than trying to rank whole policies as "stricter" in every respect. One policy can be more restrictive for scripts and another for connections. Record the specific requested resource and directive for each failure so the proposed change addresses the real restriction.
Separate enforcement from reporting
A Content-Security-Policy-Report-Only policy reports problems without enforcing that policy's blocks. It can coexist with an enforcing policy. Read the browser message carefully and inspect both header names so a report-only warning is not mistaken for the reason a request failed.
Conversely, do not conclude that nothing is enforced because a report-only header is present. Another enforcing header or applicable meta policy may still block the request. Keep each policy's mode in the evidence sheet alongside its origin and relevant directive.
Map each policy to an accountable owner
Inventory the hosting configuration, WordPress security or header plugins, and CDN response-header rules that are actually enabled. Identify who can safely review each one. Avoid disabling plugins or removing headers in production merely to discover which layer contributes a value; use approved staging comparisons and configuration evidence.
The durable design should make ownership understandable. That may mean a reviewed primary policy owner or deliberately separate policies with documented responsibilities. It does not mean combining every allowed source into a broad union, which could remove protections the original policy intentionally provided.
Test the intended request and the protections around it
On staging, reproduce one known failing request and document why it should be allowed. Then apply the narrow reviewed correction and check the entire enforcing policy set again. A successful response must satisfy the other applicable policies too, so verify the browser behavior rather than only reading a changed settings field.
Include negative tests for resources that should remain blocked. Preserve consent decisions during tracking tests and avoid opening broad script or connection access just to produce an analytics event. If a nonce-based script is involved, compare its markup and header within the same response instead of treating two unrelated requests as a matched pair.
Check cache paths and release safely
Test the relevant anonymous, authenticated, and cached page variants. Their templates or header rules may differ. Record the final response after the normal cache-refresh process, and verify that the reviewed configuration persists when the cache warms. A temporary passing request does not establish that every visitor path is corrected.
Keep a before-and-after policy record, the intended change, and the responsible owners with the deployment note. Confirm the actual script or request behavior and remove temporary diagnostic collection afterwards. If an unrelated resource becomes permitted unexpectedly, stop and review the change rather than declaring success based only on the original error disappearing. The goal is a coherent security policy with the required functionality, not simply a quieter browser console.
Illustrative diagnostic example, not customer measurements.When to bring in help
Use WordPress security-header diagnostics when hosting, a security plugin, and the CDN each manage part of the response. Bring the complete redacted policy set and a representative blocked request. Coordinate the owners before removing or broadening a policy.
Related troubleshooting
Trace a tag that fires without a successful collection request. Compare header and HTML nonce pairing.
Helpful references
CSP response-header reference. Google Tag Manager CSP guidance.