Consent banner blocked by CSP

Why this matters

A strict CSP is good security hygiene, but if it blocks the CMP itself, the site can silently lose its entire consent layer in production.

How to verify manually

1. Open DevTools console and look for CSP violations related to CMP assets.
2. Check whether the banner script, CSS, iframe, or API endpoints are blocked.
3. Compare local and production CSP behavior if the issue only appears in production.

Typical root causes

• CMP domains were not added to script-src, frame-src, or connect-src.
• Nonce or hash-based CSP rules do not include CMP inline bootstrap code.
• A deployment changed CSP headers without revalidating CMP dependencies.

GTM fix

1. Avoid relying on GTM to work around a broken CSP if the CMP assets themselves are blocked.
2. Review whether GTM-injected CMP fallbacks violate the same CSP rules.
3. Re-test after CSP updates in production headers.

WordPress fix

1. Check security plugins, host-level headers, and CDN rules that inject CSP.
2. Whitelist the CMP domains actually used by your banner setup.
3. Retest with browser cache disabled after header changes.

Generic fix

1. Whitelist only the minimal CMP origins needed for scripts, frames, and API calls.
2. Prefer targeted CSP updates instead of loosening the whole policy.
3. Version-control your CSP rules and retest the banner whenever they change.

How to confirm the fix worked

• Confirm CSP errors for CMP assets disappear.
• Confirm the banner renders and accepts user input normally.
• Run a fresh scan and verify the banner issue clears.