Una discusión intensa en Hacker News el 16 de agosto convirtió una configuración de Cloudflare en una lección operativa. El propietario de un sitio esperaba una página sin JavaScript, movió el dominio al entorno de Cloudflare y encontró en el HTML entregado un script de static.cloudflareinsights.com/beacon.min.js con data-cf-beacon. El título culpaba al cambio de nameservers, pero la frontera técnica es más precisa: el DNS por sí solo no reescribe HTML. La inserción aparece cuando el hostname está proxied y la respuesta pasa por el edge de Cloudflare.

Diagrama de HTML de origen que pasa por un proxy de borde donde se añade un pequeño beacon RUM antes del navegador

Qué ocurrió

La señal pública fue el hilo “Tell HN: Cloudflare silently injects its analytics when you switch nameservers”, con cientos de votos y más de cien comentarios al comprobarlo. Un foro no basta como base factual, así que conviene mirar la documentación. Cloudflare describe en Web Analytics y Observatory RUM un beacon JavaScript que puede insertarse automáticamente en sitios proxied. En su blog del 17 de septiembre de 2025 anunció que Web Analytics se activaría por defecto para dominios gratuitos a partir del 15 de octubre de 2025, con exclusión de tráfico de EU y UK. La documentación actual también ofrece desactivar la configuración automática o pasar a instalación manual.

Esa combinación explica la reacción. Para Cloudflare, es telemetría de rendimiento con enfoque de privacidad. Para muchos operadores, es una modificación del response de producción por un tercero sin despliegue desde el origin. Ambas cosas pueden ser ciertas: el beacon puede estar documentado y no usar cookies, pero añadir cualquier script en el edge cambia las expectativas de cambio.

DNS-only no es lo mismo que proxied

La precisión evita malas soluciones. Un registro DNS-only resuelve nombres y no pone a Cloudflare dentro de la conexión HTTPS que entrega la página; no puede añadir código al cuerpo HTML. Un registro proxied sí coloca el reverse proxy en la ruta. Allí pueden aplicarse WAF, caché, compresión, observabilidad, controles contra bots, optimizaciones y transformaciones antes de que el navegador reciba la respuesta.

En la interfaz esa diferencia puede parecer un icono naranja o gris. En arquitectura significa quién controla el camino final hacia el usuario. Para R2 custom domains, Pages, origins clásicos o subdominios, la pregunta es la misma: qué hostnames están en modo proxy y qué productos están habilitados. Si un proveedor puede añadir headers, desafiar al navegador, inyectar un beacon o transformar HTML, ya forma parte del runtime de la aplicación.

Qué son Web Analytics y RUM

Cloudflare Web Analytics se presenta como analítica de rendimiento respetuosa con la privacidad. El RUM beacon recoge datos desde APIs de rendimiento del navegador: navigation timing, resource timing, paint timing, Core Web Vitals como LCP, CLS, TTFB e INP, y métricas relacionadas con la carga de página. La documentación de data origin identifica https://static.cloudflareinsights.com/beacon.min.js como fuente del script y /cdn-cgi/rum como endpoint para sitios proxied.

También hay que ser justos con los límites. Cloudflare afirma que el beacon no accede a cookies, localStorage, sessionStorage, dirección IP ni IndexedDB, y que la IP recibida durante el manejo HTTP normal se descarta en el centro de datos más cercano. Por tanto, no es correcto describir el caso como seguimiento con cookies o malware. El problema profesional es que un valor por defecto de infraestructura cambió la página entregada.

Por qué hay enfado

El coste no es solo el tamaño de un archivo JavaScript. Hay sitios que prometen explícitamente no ejecutar JavaScript. Hay organizaciones públicas, sanitarias, financieras, educativas o de medios que mantienen inventarios de scripts de terceros. Hay equipos que revisan avisos de privacidad, registros de tratamiento, consentimiento, CSP, SRI, pruebas de seguridad y evaluación de proveedores antes de permitir código de navegador en producción.

La confianza también se ve afectada. El origin generó una secuencia de bytes y el usuario recibió otra. Para equipos con despliegues reproducibles, pruebas de integridad, políticas CSP estrictas o auditoría de supply chain, la mutación en el edge no es un detalle. Si la organización se entera por una queja o por Hacker News en lugar de por un ticket de cambio, el proceso ya falló.

No es una alarma de malware

Conviene mantener el tono técnico. Cloudflare es un proveedor de infraestructura relevante, Web Analytics es un producto oficial y la inserción automática está documentada. El beacon mide experiencia de usuario real; no se presenta como código para robar credenciales ni leer almacenamiento del navegador. Llamar ataque a todo script añadido reduce la credibilidad del análisis.

La distinción útil es autorización y control de cambios. Un script puede ser benigno y no estar autorizado para un sitio concreto. Un default puede ayudar a clientes gratuitos y aun así ser demasiado amplio para tráfico regulado. Un proveedor puede minimizar datos personales y de todos modos obligar al cliente a revisar compliance. La decisión puede ser granular: aceptable en páginas de marketing, prohibida en una aplicación autenticada, permitida en documentación tras revisión.

El problema de gobierno

El edge moderno ya no es fontanería pasiva. CDN, WAF, bot management, funciones serverless, analítica, optimización de imágenes, obfuscación de correo, challenges y productos de rendimiento se sitúan entre el origin y el usuario. Sus defaults pueden cambiar bytes, headers, ejecución de JavaScript, caché, latencia, telemetría y errores. Eso es superficie de supply chain.

Por eso las organizaciones necesitan un modelo de cambios para el edge. Las acciones de dashboard deben tener propietario. Los defaults de planes gratuitos deben revisarse como cualquier dependencia. Los anuncios del proveedor deben traducirse a zonas y hostnames concretos. Cualquier transformación automática del response body debe pasar por control de cambios cuando el sitio sea sensible, regulado o prometa una experiencia sin JavaScript.

Checklist de auditoría

Empiece con un diff. Solicite la misma página directamente al origin y por el hostname público, y compare HTML, headers e inventario de scripts. Busque static.cloudflareinsights.com, data-cf-beacon, /cdn-cgi/rum, scripts de bot management, email decode, Rocket Loader, Zaraz, challenge scripts, URLs de imágenes transformadas y endpoints de reporting inesperados. Repita en subdominios, no solo en la portada.

Revise Web Analytics, Observatory, Speed, Zaraz, Rules, Transform Rules, Page Rules, Workers routes, Snippets, Bot Management, WAF managed challenges y cache settings. La meta no es desactivar todo, sino saber qué productos pueden alterar lo que ve el navegador y quién aprobó cada uno.

Use CSP con intención. La guía de MDN explica que Content Security Policy limita qué recursos puede cargar una página. Un script-src estricto puede bloquear un beacon inesperado, y Content-Security-Policy-Report-Only permite medir impacto antes de aplicar la política. Pero CSP no sustituye la configuración: bloquear un script insertado por el proveedor puede crear ruido y pérdida de métricas si la función sigue habilitada.

Pruebe Cache-Control: public, no-transform cuando encaje. La FAQ de Cloudflare dice que con ese header el proxy no puede modificar el payload original, de modo que el beacon no se inyectará automáticamente. Aun así, no debe aplicarse a ciegas: puede desactivar optimizaciones útiles y requiere pruebas en páginas representativas.

Checklist de migración

Antes de mover un dominio, decida por hostname si debe ser DNS-only o proxied. Si necesita caché CDN o WAF, el proxy puede ser correcto. Si necesita preservar exactamente los bytes del origin, DNS-only u otra arquitectura puede ser mejor. No delegue esa decisión a un asistente de migración sin owner.

Después de activar el proxy, audite desde navegador y CLI: HTML entregado, headers, CSP reports, beacons de rendimiento, source maps, service workers, scripts de terceros y requests hacia endpoints del proveedor. Pruebe desde varias geografías si el proveedor documenta exclusiones regionales como EU/UK. Para privacidad y consentimiento, lleve hechos a compliance o asesoría; no improvise conclusiones legales.

Lección general

Este debate se repetirá con otros proveedores. Cuanto más útil es una plataforma edge, menos neutral resulta. La observabilidad es valiosa, pero debe ser explícita, revisable y reversible. La regla operativa es clara: si una configuración puede cambiar lo que recibe el navegador, debe tratarse como cambio de producción.