Cloudflare Browser Run: host approvati e revisioni senza controllo

Il 14 settembre 2026, Cloudflare Browser Run ha introdotto due controlli che cambiano il modo in cui si può consegnare a un cliente un'automazione del browser: una sessione può restare entro un elenco di hostname approvati e un revisore può seguirla tramite Live View senza ottenere controlli interattivi. È possibile indicare direttamente fino a 50 hostname oppure collegare fino a quattro set di domini condivisi, ma il punto davvero utile è il perimetro operativo, non la lunghezza dell'elenco.

Cloudflare Browser Run introduce due confini, non uno

Una sessione Browser Run è un'istanza remota di Chrome. Il codice la controlla con Puppeteer, Playwright o Chrome DevTools Protocol, generalmente abbreviato in CDP.

I nuovi guardrail di sessione stabiliscono quali hostname di destinazione il browser può contattare tramite HTTP o HTTPS. La policy viene fissata all'avvio e rimane valida per l'intera durata della sessione.

La nuova modalità in sola lettura di Live View svolge un compito diverso. Definisce che cosa può fare una persona collegata tramite uno specifico link di visualizzazione generato. Il revisore può osservare la sessione, ma non può navigare, digitare, fare clic o eseguire JavaScript.

La distinzione è importante. L'automazione continua a controllare il browser; il revisore si limita a osservarlo. Nel frattempo, tutte le richieste HTTP e HTTPS del browser restano entro l'allowlist della sessione, indipendentemente dalla connessione Live View aperta.

L'automazione del browser diventa un flusso di revisione per il cliente

Immaginiamo un'agenzia che genera un report all'interno dell'applicazione web di un cliente. Il browser deve raggiungere l'hostname principale del cliente, un hostname di autenticazione, un'API, un host per i font e, forse, una CDN per le immagini. Prima di approvare il risultato, il cliente vuole anche vedere l'esecuzione.

Ora le due esigenze possono essere gestite come decisioni separate:

1. Il responsabile tecnico approva le destinazioni necessarie alla sessione.
2. Il cliente riceve un URL Live View in sola lettura e osserva il lavoro mentre viene eseguito.

Al revisore non viene affidato un browser interattivo. Al job non viene concessa una lista aperta di destinazioni. È un passaggio di consegne più pulito rispetto all'uso dello stesso link condiviso sia come strumento dimostrativo sia come decisione sul controllo degli accessi.

Non è comunque un sistema di sicurezza completo. Cloudflare documenta il controllo degli hostname per le richieste HTTP e HTTPS, quindi non va presentato come una sandbox di rete general-purpose. Inoltre, un URL Live View contiene un JWT firmato: l'URL completo è quindi una credenziale. La sola lettura elimina l'interazione, ma espone comunque tutto ciò che compare nella pagina.

Il vero lavoro è mantenere l'elenco delle risorse

L'hostname più ovvio raramente basta a caricare l'intera pagina.

In produzione, una pagina può reindirizzare l'utente durante il login, chiamare un'API separata, caricare script da un host, immagini da un altro e font da un terzo. Cloudflare richiede di includere tutte queste dipendenze. Se ne manca una, il browser riceve un 403 per quella richiesta, con cf-mitigated: guardrails e cf-brapi-guardrails-reason: not-in-allowlist negli header della risposta.

La manutenzione dell'allowlist diventa quindi un costo reale di consegna. Ogni redesign del cliente, cambio di identity provider, sostituzione degli strumenti di analytics o migrazione della CDN può richiedere una modifica della policy e un nuovo test di validazione. Non esiste una stima universale e credibile del lavoro necessario: va misurato sui propri job.

Cloudflare offre due modi per fornire l'elenco:

• allowedDomains è l'opzione diretta e consente di inserire fino a 50 pattern di hostname nella chiamata di avvio della sessione.
• allowedDomainSets accetta fino a quattro elenchi condivisi. Possono includere il set common-cdns di Cloudflare oppure URL HTTPS che restituiscono un elenco di hostname in testo semplice.

L'elenco condiviso è utile quando molti job per clienti richiedono gli stessi servizi approvati. Ha però regole temporali precise. Cloudflare mantiene in cache un elenco ospitato fino a un'ora e ogni aggiornamento vale soltanto per le sessioni avviate dopo la lettura dell'elenco aggiornato. La policy di una sessione già in esecuzione non cambia mai in corsa.

common-cdns comporta un altro compromesso: è Cloudflare a mantenerlo e il contenuto può cambiare nel tempo. Si riduce così il lavoro sull'elenco, ma non si ottiene un'allowlist immutabile. Se un contratto o un audit richiede destinazioni stabili, è meglio indicare esplicitamente gli hostname oppure usare un proprio elenco ospitato.

Quattro team che possono usarlo fin da subito

Un responsabile tecnico d'agenzia può separare approvazione e controllo

Si autorizzano l'applicazione del cliente e le dipendenze necessarie, si esegue il job nel browser e infine si genera un link Live View in sola lettura per il responsabile account o il revisore del cliente. Possono seguire la produzione delle evidenze senza fare clic nell'applicazione né modificare l'esecuzione. Il vantaggio è una fase di revisione che non si trasforma, senza volerlo, in un passaggio del controllo operativo.

Un fondatore SaaS può rendere davvero autosufficiente un PDF

Se si genera già uno screenshot o un PDF da HTML inline attendibile, basta avviare la sessione con un array allowedDomains vuoto e senza set di domini. L'HTML viene comunque renderizzato, ma non può recuperare API, script, immagini o font esterni tramite HTTP o HTTPS. Il risultato è un'affermazione più semplice da verificare: questo rendering non ha richiesto contenuti web esterni.

Questo controllo specifico non è disponibile nelle Quick Actions, inclusi gli endpoint rapidi usati spesso per screenshot e PDF. Per applicarlo serve una Browser Session tramite Puppeteer, Playwright o CDP.

Un team di piattaforma può gestire un'unica policy per le dipendenze

Si pubblica via HTTPS un elenco in testo semplice, con un pattern di hostname per riga, e si richiama quell'URL tramite allowedDomainSets. Più sistemi di avvio delle sessioni possono usare lo stesso elenco. Il vantaggio è avere un unico punto di manutenzione, tenendo presente una regola importante: una sola riga non valida fa rifiutare l'intero elenco ospitato.

Un revisore della sicurezza può chiedere un test negativo

Non basta mostrare la configurazione. Conviene tentare una richiesta verso un hostname non autorizzato, quindi salvare il codice di stato 403 e i due header dei guardrail insieme alla documentazione della revisione. Si ottiene così la prova che il percorso negativo ha funzionato, non lo screenshot di un oggetto che sembrava configurato correttamente.

Come configurare una sessione protetta per la revisione

Serve una procedura tecnica, perché la funzionalità si configura alla creazione della sessione. Il codice seguente proviene dalle pagine Cloudflare consultate per questo articolo.

1. 1

   Installare un client compatibile e collegare il browser

   Per i guardrail, Cloudflare richiede @cloudflare/puppeteer 1.4.0 o una versione successiva. Il comando di installazione per Puppeteer è:

   npm i -D @cloudflare/puppeteer

   Anche il Worker deve avere un binding del browser. Nell'esempio Wrangler di Cloudflare si chiama 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"
   	}
   }

   Va verificata la versione del pacchetto installato. La panoramica meno recente di Puppeteer indica ancora la 1.1.0 come versione corrente, mentre la pagina più recente sui guardrail richiede la 1.4.0 o successiva. Fa fede il requisito della funzionalità.

2. 2

   Avviare la sessione con la policy delle destinazioni

   Nell'esempio Puppeteer con guardrail, Cloudflare autorizza il dominio principale, i relativi sottodomini e il set condiviso 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;
   }

   I valori di esempio vanno sostituiti soltanto dopo aver censito redirect, API, script, immagini e font usati dalla pagina. Si noti che *.example.com non include example.com: per questo compaiono entrambe le voci.

3. 3

   Dimostrare che un host non approvato viene bloccato

   Si richiede un hostname esterno all'elenco. Il risultato atteso è HTTP 403 con cf-mitigated: guardrails e cf-brapi-guardrails-reason: not-in-allowlist. Va testata anche la pagina autorizzata lungo l'intero percorso di login e rendering. Il test negativo dimostra che il confine funziona; quello positivo conferma che il job continua a funzionare.

4. 4

   Generare un link di revisione in sola lettura

   Una volta disponibile l'ID della sessione, l'esempio REST di Cloudflare crea una vista della scheda con cui il revisore non può interagire:

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

   L'URL va generato in codice server-side attendibile e condiviso tramite un canale fidato. Il tempo predefinito entro cui avviare la connessione è di cinque minuti. expiresInMs può essere impostato da un minimo di 60,000 millisecondi a un massimo di 3,600,000 millisecondi, pari a un'ora.

La ripetizione del termine guardrails può creare confusione. All'avvio della sessione contiene allowedDomains e controlla le destinazioni. Nella richiesta dell'URL Live View contiene mode: readonly e controlla quel revisore. Per ottenere entrambi i confini servono entrambe le impostazioni.

La funzionalità può spostare il job su un piano di costo diverso

L'attuale prezzario di Browser Run di Cloudflare non applica una voce separata per ogni elemento dell'allowlist. Il costo dipende invece dal metodo d'integrazione.

Le Quick Actions vengono fatturate soltanto in base alle ore di browser, ma non supportano questi guardrail. Con le Browser Sessions, invece, si pagano sia le ore di browser sia i browser concorrenti. Se un flusso rapido per PDF o screenshot deve ora limitare gli hostname, il passaggio a Puppeteer, Playwright o CDP cambia sia l'implementazione sia il modello di costo.

Con Workers Paid sono incluse 10 ore di browser al mese e 10 browser concorrenti. Il tempo aggiuntivo costa $0.09 all'ora. La concorrenza aggiuntiva costa $2.00 per browser, in base alla media mensile dei picchi giornalieri.

La formula utile per la pianificazione è:

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

L'esempio di Cloudflare usa 50 ore di browser e una media di 15 browser concorrenti. Il risultato è $3.60 per 40 ore aggiuntive, più $10.00 per cinque browser aggiuntivi, cioè $13.60 di costi extra per l'utilizzo. Non è una tariffa per i guardrail: è il costo della Browser Session legato al percorso che li supporta.

Workers Free include 10 minuti di browser al giorno e tre browser concorrenti. Possono bastare per una piccola prova, ma lasciano poco margine a un flusso per clienti con revisioni ripetute.

Se si usano già le Browser Sessions, le categorie di fatturazione non cambiano. Il nuovo costo è soprattutto operativo: censire gli host delle risorse, testare i percorsi bloccati e consentiti e tenere aggiornato l'elenco. Per chi sta ancora confrontando diversi approcci ai browser gestiti, la guida più ampia sui browser per agenti contestualizza queste voci di utilizzo.

Dove il sistema può ancora rompersi

Il problema più comune è una pagina che funziona in sviluppo e, una volta attivata l'allowlist, perde un font, un'immagine, un redirect di login o una chiamata API. Un carattere jolly troppo ampio può nascondere il guasto, ma indebolisce il confine che si voleva creare.

Cloudflare consente un solo carattere jolly per pattern di hostname. Per i sottodomini è preferibile *.example.com, indicando separatamente il dominio principale. Un pattern con prefisso come *example.com può corrispondere anche a un sosia come evilexample.com: è quindi la scorciatoia sbagliata per una policy rigorosa destinata a un cliente.

Anche Live View in sola lettura ha un limite. Protegge una singola connessione del revisore, non la sessione dal proprio operatore né un'altra connessione dalla possibilità di controllarla. Puppeteer e Playwright non possono pilotare la connessione in sola lettura perché i comandi necessari vengono bloccati. È utile per un revisore e inutile come credenziale di automazione, proprio come dovrebbe essere.

Quick Actions e Kitesurf restano escluse dalla funzionalità dei guardrail. Per i team che usano questi strumenti non cambia nulla, finché non riterranno che il confine degli hostname valga il passaggio a un altro percorso d'integrazione.

La prossima mossa operativa

Si sceglie un job reale per un cliente con un insieme stabile di destinazioni, senza partire dal flusso di login più complesso.

Si censiscono tutti gli hostname usati nel percorso che funziona, inclusi redirect e host delle risorse. Si avvia una Browser Session protetta, si verifica il risultato previsto, quindi si richiede deliberatamente un hostname non approvato e si salva la prova del 403. Infine si consegna a un collega un link Live View in sola lettura, verificando che possa osservare ma non interagire.

Dal progetto pilota vanno registrati quattro dati: il numero di hostname richiesti, il tempo dedicato alla manutenzione, il numero di richieste legittime bloccate inizialmente e il picco medio di browser concorrenti. Questi quattro valori indicano se, per quel flusso, si tratta di un controllo ben delimitato o di una promessa costosa.

Conviene agire questa settimana se si consegnano job browser ai clienti, gli host necessari sono identificabili e l'osservazione senza controllo risolve un vero problema di approvazione. Meglio aspettare se le dipendenze cambiano di continuo oppure se il job usa ancora le Quick Actions e non è stato calcolato il costo del passaggio alle Browser Sessions. Per chi non esegue Browser Sessions né condivide attività browser in tempo reale, questa novità non cambia le priorità operative.

Per ricevere altre analisi operative sui cambiamenti delle piattaforme, è possibile iscriversi alla newsletter.