Browser automation com Cloudflare: hosts aprovados e revisão somente leitura

Em 14 de setembro de 2026, o Cloudflare Browser Run ganhou dois controles que mudam a forma como uma operação de browser automation pode ser entregue a um cliente: a sessão pode ficar restrita a uma lista de hostnames aprovados, enquanto um revisor acompanha tudo pelo Live View sem receber controle interativo. É possível informar diretamente até 50 hostnames ou vincular até quatro conjuntos de domínios compartilhados, mas o que realmente importa é o limite operacional, não o tamanho da lista.

Browser automation agora tem dois limites, não apenas um

Uma sessão do Browser Run é uma instância remota do Chrome. Seu código a controla por Puppeteer, Playwright ou Chrome DevTools Protocol, geralmente chamado de CDP.

Os novos guardrails de sessão determinam quais hostnames de destino o navegador pode acessar por HTTP ou HTTPS. A política é definida quando a sessão começa e permanece em vigor durante toda a sua duração.

A nova configuração somente leitura do Live View cumpre outra função. Ela determina o que uma pessoa, usando um link de visualização específico, pode fazer. Quem recebe acesso somente leitura vê a sessão, mas não pode navegar, digitar, clicar nem executar JavaScript.

Essa diferença é importante. A automação continua no comando do navegador. O revisor apenas observa. Ao mesmo tempo, as requisições HTTP e HTTPS do navegador permanecem dentro da allowlist da sessão, independentemente de qual conexão do Live View esteja aberta.

O trabalho no navegador vira um fluxo de revisão para clientes

Imagine uma agência gerando um relatório dentro do aplicativo web de um cliente. O navegador precisa do hostname principal do cliente, de um hostname de autenticação, de uma API, de um host de fontes e, talvez, de uma CDN de imagens. O cliente também quer acompanhar a execução antes de aprovar o resultado.

Agora, essas necessidades podem ser tratadas como duas decisões separadas:

1. O responsável técnico aprova os destinos necessários para a sessão.
2. O cliente recebe uma URL do Live View somente para visualização e acompanha a execução do trabalho.

O revisor não recebe um navegador interativo. O trabalho não recebe uma lista aberta de destinos. É uma passagem de bastão mais clara do que usar o mesmo link compartilhado do navegador como ferramenta de demonstração e decisão de controle de acesso.

Ainda assim, isso não forma um sistema de segurança completo. A Cloudflare documenta controles de hostname para requisições HTTP e HTTPS, portanto não apresente o recurso como um sandbox de rede de uso geral. A URL do Live View também contém um JWT assinado, o que transforma a URL completa em uma credencial. O modo somente leitura impede interações, mas ainda expõe tudo o que aparece na página.

O trabalho de verdade está em manter a lista de recursos

O hostname mais óbvio raramente basta para carregar a página inteira.

Uma página em produção pode redirecionar durante o login, chamar uma API separada, carregar scripts de um host, imagens de outro e fontes de um terceiro. A Cloudflare orienta a incluir todas essas dependências. Se uma delas ficar de fora, o navegador recebe o status 403 para a requisição, com cf-mitigated: guardrails e cf-brapi-guardrails-reason: not-in-allowlist nos cabeçalhos da resposta.

Isso transforma a manutenção da allowlist em um custo real de entrega. Cada redesign do cliente, troca de provedor de identidade ou analytics e migração de CDN pode exigir uma mudança na política e uma nova rodada de validação. Não existe uma estimativa universal e honesta do esforço necessário. Meça esse custo nos seus próprios trabalhos.

A Cloudflare oferece duas formas de fornecer a lista:

• allowedDomains é a opção direta, com até 50 padrões de hostname na chamada que inicia a sessão.
• allowedDomainSets aceita até quatro listas compartilhadas. Elas podem incluir o conjunto common-cdns da Cloudflare ou URLs HTTPS que retornem uma lista de hostnames em texto simples.

A lista compartilhada é útil quando muitos trabalhos de clientes dependem dos mesmos serviços aprovados. Ela também segue regras de atualização. A Cloudflare mantém uma lista hospedada em cache por até uma hora, e qualquer alteração só afeta as sessões iniciadas depois que a lista atualizada é lida. A política de uma sessão em andamento nunca muda durante a execução.

Há outro ponto de atenção no common-cdns: a Cloudflare mantém esse conjunto e pode alterá-lo com o tempo. Isso reduz o trabalho de manutenção, mas não equivale a uma allowlist fixa. Se um contrato ou uma auditoria exigir destinos estáveis, informe os hostnames explicitamente ou use sua própria lista hospedada.

Quatro equipes que já podem usar esse recurso

A liderança técnica de uma agência pode separar aprovação e controle

Libere o aplicativo do cliente e as dependências necessárias, execute o trabalho no navegador e, em seguida, gere um link do Live View somente leitura para a pessoa responsável pela conta ou pela revisão do lado do cliente. Ela pode acompanhar as evidências surgirem sem clicar no aplicativo nem alterar a execução. O ganho está em criar uma etapa de revisão que não se transforma silenciosamente na transferência do papel de operador.

Um fundador de SaaS pode manter um PDF autocontido de ponta a ponta

Se você já gera uma captura de tela ou um PDF a partir de HTML inline confiável, inicie a sessão com um array allowedDomains vazio e sem conjuntos de domínios. O HTML ainda será renderizado, mas não conseguirá buscar uma API, um script, uma imagem ou uma fonte externa por HTTP ou HTTPS. O resultado é uma afirmação mais simples de testar: esta renderização não solicitou conteúdo externo da web.

Esse controle específico não está disponível em Quick Actions, inclusive nos endpoints de atalho usados com frequência para capturas de tela e PDFs. Para utilizá-lo, é preciso abrir uma Browser Session por Puppeteer, Playwright ou CDP.

Uma equipe de plataforma pode centralizar a política de dependências

Hospede uma lista em texto simples por HTTPS, coloque um padrão de hostname em cada linha e referencie essa URL por allowedDomainSets. Vários inicializadores de sessão podem usar a mesma lista. O benefício é ter um único ponto de manutenção, com uma regra importante: uma única linha inválida faz a lista hospedada inteira ser rejeitada.

Um revisor de segurança pode exigir um teste de falha

Não pare na demonstração da configuração. Tente fazer uma requisição para um hostname que não esteja liberado e salve o status 403 e os dois cabeçalhos de guardrail junto ao registro da revisão. Assim, você comprova que o caminho negativo funcionou, em vez de guardar apenas uma captura de tela de um objeto que parecia correto.

Como configurar uma sessão protegida para revisão

Este é um passo a passo técnico porque o recurso é definido no momento de criar a sessão. O código abaixo vem das páginas da Cloudflare consultadas para este artigo.

1. 1

   Instale um cliente compatível e vincule o navegador

   A Cloudflare exige @cloudflare/puppeteer 1.4.0 ou uma versão posterior para usar guardrails. O comando de instalação do Puppeteer indicado pela empresa é:

   npm i -D @cloudflare/puppeteer

   Seu Worker também precisa de um browser binding. No exemplo da Cloudflare para o Wrangler, ele recebe o nome 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"
   	}
   }

   Confira a versão instalada do pacote. A página mais antiga de visão geral do Puppeteer ainda identifica a versão 1.1.0 como a atual, mas a página mais recente de guardrails exige a 1.4.0 ou posterior. Siga o requisito do recurso.

2. 2

   Inicie a sessão com a política de destinos

   O exemplo protegido da Cloudflare com Puppeteer libera o domínio raiz, seus subdomínios e o conjunto compartilhado 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;
   }

   Substitua os valores de exemplo somente depois de mapear os redirecionamentos, as APIs, os scripts, as imagens e as fontes da página. Observe que *.example.com não inclui example.com; por isso, as duas entradas aparecem.

3. 3

   Comprove que um host não aprovado é bloqueado

   Faça uma requisição para um hostname fora da lista. O resultado esperado é HTTP 403, com cf-mitigated: guardrails e cf-brapi-guardrails-reason: not-in-allowlist. Teste também a página aprovada em todo o fluxo de login e renderização. O teste negativo comprova o limite; o positivo confirma que o trabalho continua funcionando.

4. 4

   Gere um link de revisão somente para visualização

   Com o ID da sessão em mãos, o exemplo de REST da Cloudflare cria uma visualização de aba na qual o revisor não pode interagir:

   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"
   		}
   	}'

   Gere essa URL em código confiável executado no servidor e compartilhe-a por um canal seguro. O prazo padrão para iniciar a conexão é de cinco minutos. O valor de expiresInMs pode ser definido a partir de 60,000 milissegundos até 3,600,000 milissegundos, o equivalente a uma hora.

A repetição da palavra guardrails pode causar confusão. Na inicialização da sessão, ela contém allowedDomains e controla os destinos. Na solicitação da URL do Live View, ela contém mode: readonly e controla aquele revisor. Se você precisa dos dois limites, deve aplicar as duas configurações.

O recurso pode levar o trabalho para outra modalidade de cobrança

Os preços atuais do Browser Run não têm uma cobrança separada para cada entrada da allowlist. O custo muda quando o método de integração muda.

Quick Actions são cobradas apenas pelas horas de navegador, mas não aceitam esses guardrails. Browser Sessions aceitam guardrails e são cobradas pelas horas de navegador mais os navegadores simultâneos. Se um fluxo simplificado de PDF ou captura de tela agora precisa restringir hostnames, migrar para Puppeteer, Playwright ou CDP muda tanto a implementação quanto o modelo de custos.

No Workers Paid, a franquia inclui 10 horas de navegador por mês e 10 navegadores simultâneos. O tempo adicional de navegador custa $0.09 por hora. A simultaneidade adicional custa $2.00 por navegador, com base na média mensal do pico de cada dia.

A fórmula útil para o planejamento é:

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

O exemplo da própria Cloudflare usa 50 horas de navegador e uma média de 15 navegadores simultâneos. Isso resulta em $3.60 por 40 horas adicionais, mais $10.00 por cinco navegadores extras, ou $13.60 em cobranças de uso adicional. Não se trata de uma tarifa de guardrail. É a conta de Browser Session associada ao caminho que oferece suporte a guardrails.

O Workers Free inclui 10 minutos de navegador por dia e três navegadores simultâneos. Pode ser suficiente para uma pequena prova de conceito, mas oferece pouca margem para um fluxo de cliente com várias rodadas de revisão.

Se você já utiliza Browser Sessions, as categorias de cobrança não mudam. O novo custo é principalmente operacional: levantar os hosts de recursos, testar os caminhos bloqueados e permitidos e manter a lista atualizada. Caso ainda esteja comparando abordagens gerenciadas para navegadores, o guia mais amplo sobre navegadores para agentes de IA contextualiza esses itens de uso.

Onde essa abordagem ainda pode falhar

A falha mais comum é uma página funcionar no desenvolvimento e perder uma fonte, imagem, redirecionamento de login ou chamada de API depois que a allowlist entra em vigor. Um wildcard amplo pode fazer o problema desaparecer, mas também enfraquece o limite que você pretendia criar.

A Cloudflare permite um wildcard por padrão de hostname. Prefira *.example.com para subdomínios e liste o domínio raiz separadamente. Um padrão de prefixo como *example.com também pode corresponder a um endereço parecido, como evilexample.com; por isso, é um atalho inadequado para uma política de cliente rigorosa.

O Live View somente leitura tem seu próprio limite. Ele protege uma conexão de visualização, não protege a sessão de quem a opera nem impede que outra conexão a controle. Puppeteer e Playwright não conseguem controlar a conexão somente leitura porque os comandos necessários são bloqueados. Isso é útil para um revisor e inútil como credencial de automação — exatamente como deveria ser.

Quick Actions e Kitesurf continuam fora do recurso de guardrails. Equipes que usam qualquer uma dessas opções não são afetadas até decidirem que o limite de hostname justifica a mudança no caminho de integração.

O que colocar em prática na segunda-feira

Escolha um trabalho real de cliente com um conjunto estável de destinos. Não comece pelo seu fluxo de login mais complicado.

Mapeie todos os hostnames usados no caminho bem-sucedido, incluindo redirecionamentos e hosts de recursos. Inicie uma Browser Session protegida, confirme o resultado esperado e depois tente acessar deliberadamente um hostname não aprovado, salvando a evidência do status 403. Por fim, entregue a um colega um link do Live View somente leitura e confirme que ele consegue acompanhar, mas não interagir.

Registre quatro dados desse piloto: a quantidade necessária de hostnames, o tempo gasto na manutenção, o número de requisições legítimas bloqueadas inicialmente e o pico médio de navegadores simultâneos. Esses quatro valores mostram se, para aquele fluxo, o recurso é um controle simples ou uma promessa cara.

Adote ainda nesta semana se você entrega trabalhos de navegador a clientes, conhece os hosts necessários e a observação sem controle resolve um problema real de aprovação. Espere se suas dependências mudam o tempo todo ou se o trabalho ainda roda em Quick Actions e você não calculou o custo da migração para Browser Sessions. Se você não executa Browser Sessions nem compartilha trabalhos de navegador ao vivo, esse lançamento não muda o que você fará na segunda-feira.

Se você quer receber mais análises de mudanças em plataformas com foco em quem opera os sistemas, assine a newsletter.