Automatización de navegador con Cloudflare: destinos aprobados y revisión de solo lectura

El 14 de septiembre de 2026, Cloudflare Browser Run incorporó dos controles que cambian la forma de entregar automatización de navegador a un cliente: una sesión puede mantenerse dentro de una lista de nombres de host aprobados y un revisor puede seguirla mediante Live View sin obtener control interactivo. Es posible indicar directamente hasta 50 nombres de host o asociar hasta cuatro conjuntos de dominios compartidos, pero lo importante no es el tamaño de la lista, sino el límite operativo.

El cambio introduce dos límites, no uno

Una sesión de Browser Run es una instancia remota de Chrome. El código la controla con Puppeteer, Playwright o Chrome DevTools Protocol, habitualmente abreviado como CDP.

Los nuevos límites de sesión determinan a qué nombres de host de destino puede hacer solicitudes HTTP o HTTPS el navegador. La política se fija al iniciar la sesión y se mantiene durante toda su vigencia.

La nueva configuración de solo lectura de Live View cumple otra función. Define lo que puede hacer una persona que accede mediante un enlace de visualización concreto. Quien entra en modo de solo lectura puede ver la sesión, pero no navegar, escribir, hacer clic ni evaluar JavaScript.

La diferencia es fundamental. La automatización conserva el control del navegador; el revisor se limita a observar. A la vez, las solicitudes HTTP y HTTPS del navegador permanecen dentro de la lista permitida de la sesión, independientemente de qué conexión de Live View esté abierta.

Así se convierte el trabajo del navegador en un flujo de revisión para clientes

Pensemos en una agencia que genera un informe dentro de la aplicación web de un cliente. El navegador necesita el nombre de host principal del cliente, otro para la autenticación, una API, un host de fuentes y quizá un CDN de imágenes. Antes de aprobar el resultado, el cliente también quiere ver cómo se ejecuta el proceso.

Ahora ambas cuestiones pueden resolverse como decisiones independientes:

1. El responsable técnico aprueba los destinos que necesita la sesión.
2. El cliente recibe una URL de Live View de solo lectura y observa la ejecución.

El revisor no recibe un navegador interactivo. El trabajo tampoco obtiene una lista abierta de destinos. Es una entrega más clara que usar un mismo enlace compartido del navegador como herramienta de demostración y, al mismo tiempo, como decisión de control de acceso.

Aun así, no constituye un sistema de seguridad completo. Cloudflare documenta controles de nombres de host para solicitudes HTTP y HTTPS, por lo que no conviene presentarlos como un entorno aislado de red de uso general. Además, una URL de Live View contiene un JWT firmado: la URL completa es una credencial. El modo de solo lectura impide la interacción, pero sigue mostrando todo lo que aparezca en la página.

El verdadero trabajo está en mantener la lista de dominios permitidos

El nombre de host más evidente casi nunca basta para cargar toda la página.

Una página en producción puede redirigir durante el inicio de sesión, consultar una API independiente y cargar scripts desde un host, imágenes desde otro y fuentes desde un tercero. Cloudflare indica que deben incluirse todas esas dependencias. Si falta una, el navegador recibe un 403 para esa solicitud, con cf-mitigated: guardrails y cf-brapi-guardrails-reason: not-in-allowlist en los encabezados de respuesta.

Por eso, mantener la lista permitida representa un costo real de entrega. Cualquier rediseño del cliente, cambio de proveedor de identidad, sustitución del sistema de analítica o migración de CDN puede exigir una modificación de la política y otra ejecución de validación. No existe una cifra universal y honesta para ese trabajo: debe medirse en las tareas reales de cada equipo.

Cloudflare ofrece dos formas de suministrar la lista:

• allowedDomains es la opción directa y admite hasta 50 patrones de nombres de host en la llamada que inicia la sesión.
• allowedDomainSets admite hasta cuatro listas compartidas. Pueden incluir el conjunto common-cdns de Cloudflare o URL HTTPS que devuelvan una lista de nombres de host en texto sin formato.

La lista compartida resulta práctica cuando muchos trabajos de clientes requieren los mismos servicios aprobados. También tiene reglas de actualización. Cloudflare guarda en caché una lista alojada durante un máximo de una hora, y los cambios solo afectan a las sesiones iniciadas después de que se lea la lista actualizada. La política de una sesión en curso nunca cambia durante la ejecución.

common-cdns plantea otra decisión: Cloudflare mantiene ese conjunto y puede modificarlo con el tiempo. Así se reduce el mantenimiento, pero deja de ser una lista permitida fija. Si un contrato o una auditoría exige destinos estables, conviene declarar los nombres de host de forma explícita o alojar una lista propia.

Cuatro equipos que ya pueden aprovecharlo

El responsable técnico de una agencia puede separar aprobación y control

El responsable técnico autoriza la aplicación del cliente y sus dependencias, ejecuta el trabajo del navegador y después genera un enlace de Live View de solo lectura para el equipo de cuenta o el revisor del cliente. Así pueden ver cómo aparece la evidencia sin acceder a la aplicación ni alterar la ejecución. El beneficio es una etapa de revisión que no se convierte discretamente en una transferencia del control operativo.

Un fundador de SaaS puede generar un PDF sin dependencias externas

Si ya se genera una captura de pantalla o un PDF a partir de HTML inline confiable, la sesión puede iniciarse con un array allowedDomains vacío y sin conjuntos de dominios. El HTML se renderiza, pero no puede acceder por HTTP o HTTPS a una API, un script, una imagen ni una fuente externos. El beneficio es una afirmación más sencilla de comprobar: este renderizado no solicitó contenido web externo.

Este control específico no está disponible en Quick Actions, incluidos los endpoints abreviados que suelen utilizarse para capturas y PDF. Para aplicarlo se necesita una Browser Session mediante Puppeteer, Playwright o CDP.

Un equipo de plataforma puede administrar una sola política de dependencias

Se aloja por HTTPS una lista en texto sin formato, se coloca un patrón de nombre de host en cada línea y se referencia esa URL mediante allowedDomainSets. Varios componentes que inician sesiones pueden usar la misma lista. El beneficio es un único punto de mantenimiento, con una regla importante: una sola línea no válida provoca el rechazo de toda la lista alojada.

Un revisor de seguridad puede exigir una prueba que falle

No basta con mostrar la configuración. Hay que intentar una solicitud a un nombre de host no permitido y guardar el estado 403 y los dos encabezados de los límites junto con el registro de la revisión. El beneficio es demostrar que funcionó el caso negativo, no conservar una captura de un objeto que parecía correcto.

Cómo configurar una sesión de automatización de navegador protegida

Esta parte es técnica porque la función se define al crear la sesión. El código siguiente procede de las páginas de Cloudflare consultadas para este artículo.

1. 1

   Instalar un cliente compatible y vincular el navegador

   Cloudflare exige @cloudflare/puppeteer 1.4.0 o posterior para utilizar los límites. Su comando de instalación para Puppeteer es:

   npm i -D @cloudflare/puppeteer

   El Worker también necesita un binding del navegador. En el ejemplo de Wrangler de Cloudflare se denomina MYBROWSER:

   {
   	"$schema": "./node_modules/wrangler/config-schema.json",
   	"name": "browser-rendering",
   	"main": "src/index.ts",
   	"workers_dev": true,
   	"compatibility_flags": ["nodejs_compat_v2"],
   	"browser": {
   		"binding": "MYBROWSER"
   	}
   }

   Es importante comprobar la versión del paquete instalado. La guía anterior de Puppeteer todavía presenta 1.1.0 como la versión actual, pero la página más reciente sobre límites exige 1.4.0 o posterior. En este caso prevalece el requisito de la función.

2. 2

   Iniciar la sesión con la política de destinos

   El ejemplo de Puppeteer con esta protección que ofrece Cloudflare permite el dominio raíz, sus subdominios y el conjunto compartido common-cdns:

   import puppeteer from "@cloudflare/puppeteer";
   
   export async function startGuardedSession(env) {
   	const browser = await puppeteer.launch(env.MYBROWSER, {
   		guardrails: {
   			allowedDomains: ["example.com", "*.example.com"],
   			allowedDomainSets: ["common-cdns"],
   		},
   	});
   
   	return browser;
   }

   Los valores del ejemplo solo deben reemplazarse después de inventariar las redirecciones, las API, los scripts, las imágenes y las fuentes de la página. Obsérvese que *.example.com no incluye example.com; por eso aparecen las dos entradas.

3. 3

   Demostrar que un host no aprobado queda bloqueado

   Se solicita un nombre de host que no esté en la lista. El resultado esperado es HTTP 403 con cf-mitigated: guardrails y cf-brapi-guardrails-reason: not-in-allowlist. También hay que probar la página aprobada en todo su recorrido de inicio de sesión y renderizado. Una prueba negativa demuestra el límite; una positiva confirma que el trabajo sigue funcionando.

4. 4

   Generar un enlace de revisión de solo lectura

   Una vez disponible el ID de la sesión, el ejemplo REST de Cloudflare crea una vista de la pestaña que impide al revisor interactuar:

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/browser-rendering/devtools/browser/$SESSION_ID/live_view" \
   	--request POST \
   	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
   	--json '{
   		"mode": "tab",
   		"guardrails": {
   			"mode": "readonly"
   		}
   	}'

   Esta URL debe generarse en código confiable del lado del servidor y compartirse por un canal de confianza. El plazo predeterminado para iniciar la conexión es de cinco minutos. expiresInMs admite desde 60,000 milisegundos hasta 3,600,000 milisegundos, es decir, una hora.

La repetición de la palabra guardrails puede generar confusión. Al iniciar la sesión, contiene allowedDomains y controla los destinos. En la solicitud de URL de Live View, contiene mode: readonly y controla a ese revisor. Para establecer ambos límites se necesitan las dos configuraciones.

La función puede trasladar un trabajo a otra modalidad de facturación

Los precios actuales de Browser Run de Cloudflare no incluyen un cargo independiente por cada elemento de la lista permitida. El costo cambia cuando se modifica el método de integración.

Con Quick Actions solo se cobran las horas de navegador, pero estos límites no están disponibles. En Browser Sessions sí pueden utilizarse, y se cobran tanto las horas de navegador como los navegadores simultáneos. Si un flujo de PDF o capturas mediante Quick Actions ahora necesita restricciones de nombres de host, trasladarlo a Puppeteer, Playwright o CDP cambia tanto la implementación como el modelo de costos.

En Workers Paid, el uso incluido es de 10 horas de navegador al mes y 10 navegadores simultáneos. El tiempo adicional cuesta $0.09 por hora. La simultaneidad adicional cuesta $2.00 por navegador, según el promedio mensual del máximo diario.

La fórmula útil para planificar es:

extra usage cost = max(0, browser hours - 10) × $0.09 + max(0, average daily peak browsers - 10) × $2.00

El ejemplo de Cloudflare utiliza 50 horas de navegador y un promedio de 15 navegadores simultáneos. El resultado es $3.60 por 40 horas adicionales, más $10.00 por cinco navegadores adicionales: $13.60 en cargos extra por uso. No es una tarifa por los límites; es la factura de Browser Session asociada a la modalidad que los admite.

Workers Free incluye 10 minutos de navegador al día y tres navegadores simultáneos. Puede alcanzar para una prueba pequeña, pero deja muy poco margen para un flujo de clientes con varias ejecuciones de revisión.

Si ya se utiliza Browser Sessions, las categorías de facturación no cambian. El nuevo costo es principalmente operativo: recopilar los hosts de recursos, probar rutas bloqueadas y permitidas, y mantener actualizada la lista. Para quienes todavía comparan alternativas de navegadores administrados, la guía general de navegadores para agentes de IA pone estas partidas de uso en contexto.

En qué casos todavía falla

El fallo más fácil de encontrar es el de una página que funciona durante el desarrollo, pero pierde una fuente, una imagen, una redirección de inicio de sesión o una llamada a la API al activar la lista permitida. Un comodín demasiado amplio puede ocultar el problema a costa de debilitar el límite que se quería imponer.

Cloudflare permite un comodín por patrón de nombre de host. Es preferible usar *.example.com para los subdominios y declarar el dominio raíz por separado. Un patrón de prefijo como *example.com también puede coincidir con un nombre parecido, por ejemplo evilexample.com, así que no sirve como atajo para una política de cliente estricta.

Live View de solo lectura tiene su propia limitación. Protege una conexión de visualización, no protege la sesión frente a su operador ni impide que otra conexión la controle. Puppeteer y Playwright no pueden operar a través de la conexión de solo lectura porque los comandos necesarios están bloqueados. Eso la hace útil para un revisor e inútil como credencial de automatización, justo lo esperado.

Quick Actions y Kitesurf siguen fuera de la función de guardrails. Los equipos que utilicen cualquiera de los dos no notarán cambios hasta que decidan que restringir los nombres de host justifica cambiar el método de integración.

Qué hacer el lunes

Conviene elegir un trabajo real de cliente con un conjunto estable de destinos, no el flujo de inicio de sesión más complejo.

Primero se deben inventariar todos los nombres de host utilizados por el recorrido correcto, incluidas las redirecciones y los hosts de recursos. Después se inicia una Browser Session protegida, se confirma el resultado previsto y se solicita deliberadamente un nombre de host no aprobado para guardar la evidencia del 403. Por último, se entrega a un compañero un enlace de Live View de solo lectura y se verifica que pueda mirar, pero no interactuar.

Del piloto deben registrarse cuatro datos: la cantidad de nombres de host necesarios, el tiempo dedicado a mantenerlos, el número de solicitudes legítimas bloqueadas al principio y el promedio de los máximos diarios de navegadores simultáneos. Esos cuatro valores revelan si, para ese flujo, se trata de un control claro o de una promesa costosa.

Vale la pena actuar esta semana si se entregan trabajos de navegador a clientes, es posible conocer los nombres de host necesarios y observar sin controlar resuelve un problema real de aprobación. Conviene esperar si las dependencias cambian continuamente o si el trabajo todavía usa Quick Actions y no se ha calculado el costo de pasar a Browser Session. Si no se ejecutan Browser Sessions ni se comparte trabajo de navegador en vivo, este lanzamiento no cambia lo que habrá que hacer el lunes.

Para recibir más explicaciones prácticas sobre cambios en plataformas, puede suscribirse al boletín.