Find tags blocked by a Content Security Policy

Why CSP blocks are easy to miss

A Content Security Policy tells the browser which hosts a page may load scripts from and send data to. When a tag tries to send a hit to a host the policy doesn't allow, the browser refuses before the request ever reaches the network. There's no row in the Network tab to inspect, only a console line and a violation event. The hit simply disappears.

ODDVX listens for those violation events and turns each one into a failed request row, with the reason. The exact failure the inspector exists to find is never silently left out.

Read the CSP status of each request

Every request, failed or delivered, shows how the page's policies treat it:

• Enforced policy: whether it allows the request. If not, the request was blocked.
• Report-only policy: whether it would allow it. If not, the request went through but would be reported, which is a warning of a block to come.
• The directive that applied, usually connect-src for hits and script-src for tag libraries, and the policy text, which you can copy for the developers.

Which directive blocks what

The directive tells you how much was lost:

• script-src controls which scripts may load. If it doesn't allow Google Tag Manager's host, gtm.js never loads and nothing fires: no GA4, no pixels, no Custom HTML. The page shows zero hits. Custom HTML tags that inject their own scripts need their hosts allowed here too.
• connect-src controls where scripts may send data. A gap here lets tags fire but makes their hits vanish. This is the classic server-side tagging block.
• img-src controls image requests. Some ad pixels, and fallback hits, are sent as images.
• frame-src controls iframes. Floodlight and some ad tags load in frames.

A policy without a specific directive falls back to default-src, so a strict default can block hits even when no connect-src line exists.

Fix the policy, not the tag

The fix is to add the missing host to the right directive. The most common cause is a move to server-side tagging or first-party mode: hits that used to go to a Google host now go to a subdomain of the brand's own site, which the existing policy doesn't list. The tags are fine; the policy needs the new endpoint.

Test a new policy safely

1. Ship the new policy as report-only, so nothing is blocked.
2. Inspect the key pages and look for "would be reported" rows.
3. Fix the policy until there are none.
4. Switch it to enforced and inspect again.

Keep going

• Next: ad pixels and console errors
• Read delivery verdicts
• Inspect every collect request