CSP de Cloudflare: Cómo solucionar el bloqueo de beacon.min.js

Si acabas de activar los servicios de Cloudflare en tu web y la consola del navegador ha empezado a escupir errores de violación de Content Security Policy, no estás solo. Es un síntoma clásico de un sitio bien protegido donde la seguridad choca frontalmente con las herramientas de optimización externas. El script beacon.min.js es esencial para las métricas de rendimiento, pero si tu servidor no lo autoriza explícitamente, el navegador simplemente colgará la llamada por seguridad.

#Identificando el síntoma: ¿Por qué falla ahora?

El problema no es de Cloudflare. El problema es que tu configuración de seguridad está haciendo su trabajo «demasiado bien». Al usar las DNS de Cloudflare y activar opciones como Rocket Loader o las analíticas web, la plataforma inyecta dinámicamente pequeños scripts para medir el rendimiento real del usuario.

Tu navegador lee la cabecera Content-Security-Policy enviada por tu servidor. Si esta cabecera dice que solo se permiten scripts de 'self' o dominios específicos de Google, cualquier intento de contactar con static.cloudflareinsights.com será bloqueado automáticamente. Es una protección vital contra ataques XSS, pero requiere mantenimiento cuando añadimos nuevos proveedores de servicios.

#La solución definitiva en el archivo .htaccess

Para corregir esto de forma global y eficiente, debemos atacar la raíz: los encabezados que envía el servidor Apache. No basta con añadir el script en el HTML; el permiso debe venir firmado desde el nivel de servidor. Personalmente, prefiero gestionar esto en el .htaccess antes que en el código de aplicación, ya que es más rápido y menos propenso a errores de ejecución de PHP.

Configurar en la raíz del sitio dentro de .htaccess:

# Actualizamos la directiva CSP para incluir los dominios de Cloudflare
# Añadimos https://static.cloudflareinsights.com a script-src
# Añadimos https://cloudflareinsights.com a connect-src

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.jsdelivr.net https://static.cloudflareinsights.com; connect-src 'self' https://cdn.jsdelivr.net https://cloudflareinsights.com; img-src 'self' data: https:;"

Fíjate que hemos añadido el dominio en dos sitios. En script-src para que el navegador pueda descargar el archivo JS, y en connect-src para que ese mismo script tenga permiso para enviar los datos de vuelta a los servidores de Cloudflare mediante peticiones asíncronas.

#Cuidado con las políticas duplicadas en PHP

Un error muy común —que yo mismo he cometido alguna vez— es intentar solucionar esto mediante un filtro wp_headers en el archivo functions.php mientras ya tienes las cabeceras activas en el .htaccess. El resultado es que el servidor envía dos cabeceras CSP distintas. El navegador, ante la duda, aplicará la combinación más restrictiva de ambas, por lo que el bloqueo persistirá.

#Caso real: El misterio de las métricas vacías

Hace poco me encontré con este escenario en un proyecto que acababa de migrar a un stack de seguridad «blindado». Pasamos tres días preguntándonos por qué el panel de Cloudflare no mostraba datos de tráfico real a pesar de tener el proxy activo. Fue frustrante porque no había errores visuales en la web.

El Síntoma Clínico: Al abrir la consola del inspector (F12) para revisar un error de CSS totalmente ajeno, me topé con una cascada de advertencias en rojo. El mensaje era claro: «violates the following Content Security Policy directive».

El Intento Fallido: Mi primera reacción fue desactivar el CSP por completo para probar. Error de novato. El sitio funcionó, pero lo dejamos expuesto. Luego intenté añadir solo el dominio base sin el subdominio static., lo cual tampoco sirvió de nada porque Cloudflare utiliza infraestructuras distintas para servir el script y para recibir los informes. Al final, la única forma limpia fue mapear exactamente ambos puntos de contacto en el .htaccess.

#Pros y contras de esta configuración

#¿Es esta solución para ti?

Esta técnica es obligatoria si utilizas el «Browser Insights» o las analíticas web gratuitas de Cloudflare. Si solo usas Cloudflare como CDN puro o caché de borde sin funciones de inyección de scripts (como Rocket Loader), es probable que no necesites abrir estos permisos.

En el panorama actual de seguridad web, ser restrictivo es la norma. Pero como ingenieros, debemos saber cuándo y cómo dar paso a los servicios legítimos que ayudan a nuestro sitio a ser más rápido. No es lógico mantener una puerta cerrada a cal y canto si eso impide que el sistema de vigilancia (en este caso, las métricas de Cloudflare) informe de posibles intrusos o cuellos de botella.

Esto lo escribo en febrero de 2026. Si para cuando leas esto Cloudflare ha unificado sus dominios bajo un solo endpoint, revisa su documentación actualizada, aunque la lógica del permiso en la cabecera CSP seguirá siendo la misma.