Banner de consentimiento bloqueado por CSP

Por qué es importante

Una CSP estricta es una buena práctica de seguridad, pero si bloquea al propio CMP el sitio puede perder silenciosamente toda su capa de consentimiento en producción.

Cómo verificarlo manualmente

1. Abra la consola DevTools y busque violaciones CSP relacionadas con assets del CMP.
2. Compruebe si el script del banner, CSS, iframe o endpoints API están bloqueados.
3. Compare el comportamiento CSP entre local y producción si el problema solo aparece en producción.

Causas típicas

• Los dominios del CMP no están permitidos en script-src, frame-src o connect-src.
• Las reglas CSP basadas en nonce o hash no cubren el código inline de bootstrap del CMP.
• Un despliegue cambió headers CSP sin revalidar las dependencias del CMP.

Corrección en GTM

1. No se apoye en GTM como parche si los assets del CMP están bloqueados por la propia CSP.
2. Revise si fallbacks CMP inyectados vía GTM chocan con las mismas reglas CSP.
3. Vuelva a probar tras actualizar headers CSP en producción.

Corrección en WordPress o plugins CMP

1. Revise plugins de seguridad, headers del hosting y reglas CDN que inyecten CSP.
2. Autorice solo los dominios CMP realmente usados por su configuración de banner.
3. Vuelva a probar después de cambiar headers con la caché del navegador desactivada.

Corrección genérica para desarrolladores

1. Autorice solo los orígenes CMP mínimos necesarios para scripts, frames y llamadas API.
2. Prefiera ajustes CSP dirigidos frente a relajar toda la política.
3. Versione sus reglas CSP y vuelva a probar el banner en cada cambio.

Cómo confirmar que la corrección funciona

• Confirme que desaparecen los errores CSP relacionados con assets CMP.
• Confirme que el banner se renderiza con normalidad y acepta interacción del usuario.
• Lance un nuevo escaneo y verifique que desaparece la incidencia del banner.