Cloudflare Browser Run : des sessions client limitées aux domaines approuvés

Le 14 septembre 2026, Cloudflare Browser Run a ajouté deux réglages qui changent la manière de livrer une automatisation de navigateur à un client : une session peut rester cantonnée à une liste de noms d’hôte approuvés, tandis qu’une personne chargée de la validation peut suivre son exécution dans Live View sans obtenir de contrôle interactif. Il est possible de déclarer directement jusqu’à 50 noms d’hôte ou d’associer jusqu’à quatre ensembles de domaines partagés. Mais l’intérêt réel réside dans la frontière opérationnelle ainsi créée, pas dans la longueur de la liste.

Cloudflare Browser Run ajoute deux périmètres distincts

Une session Browser Run est une instance distante de Chrome. Le code la pilote avec Puppeteer, Playwright ou le Chrome DevTools Protocol, généralement abrégé en CDP.

Les nouveaux garde-fous de session déterminent les noms d’hôte de destination que le navigateur peut solliciter en HTTP ou HTTPS. Cette politique est fixée au démarrage et reste en vigueur pendant toute la durée de la session.

Le nouveau mode lecture seule de Live View remplit une autre fonction. Il définit les actions autorisées à une personne connectée au moyen d’un lien de visualisation donné. Celle-ci voit la session, mais ne peut ni naviguer, ni saisir du texte, ni cliquer, ni évaluer du JavaScript.

La nuance est importante. L’automatisation conserve le contrôle du navigateur ; la personne chargée de valider ne fait qu’observer. Parallèlement, les requêtes HTTP et HTTPS du navigateur restent limitées à la liste d’autorisation de la session, quelle que soit la connexion Live View ouverte.

L’automatisation de navigateur devient un workflow de validation client

Prenons une agence qui génère un rapport dans l’application web d’un client. Le navigateur doit accéder au nom d’hôte principal, à un service d’authentification, à une API, à un serveur de polices et, éventuellement, à un CDN d’images. Le client souhaite aussi voir l’exécution avant de valider le livrable.

Ces besoins peuvent désormais être traités comme deux décisions séparées :

1. Le responsable technique approuve les destinations nécessaires à la session.
2. Le client reçoit une URL Live View en lecture seule et regarde la tâche s’exécuter.

La personne chargée de la validation n’obtient pas un navigateur interactif, et la tâche ne bénéficie pas d’une liste de destinations ouverte. Ce passage de relais est plus net qu’un lien de navigateur partagé qui servirait à la fois d’outil de démonstration et de mécanisme de contrôle d’accès.

Ce dispositif ne constitue toujours pas un système de sécurité complet. Cloudflare documente le contrôle des noms d’hôte pour les requêtes HTTP et HTTPS : il ne faut donc pas le présenter comme une sandbox réseau généraliste. Une URL Live View contient par ailleurs un JWT signé, ce qui fait de l’URL complète un identifiant d’accès. Le mode lecture seule empêche les interactions, mais il expose malgré tout tout ce qui s’affiche à l’écran.

Le vrai chantier : tenir à jour la liste des ressources

Le nom d’hôte le plus évident suffit rarement à charger toute la page.

En production, une page peut rediriger l’utilisateur pendant la connexion, appeler une API distincte, charger les scripts depuis un hôte, les images depuis un autre et les polices depuis un troisième. Cloudflare demande d’inclure toutes ces dépendances. Si l’une d’elles manque, le navigateur reçoit un statut 403 pour la requête concernée, accompagné des en-têtes cf-mitigated: guardrails et cf-brapi-guardrails-reason: not-in-allowlist.

L’entretien de la liste d’autorisation devient donc un véritable coût de livraison. Chaque refonte chez le client, changement de fournisseur d’identité, remplacement d’un outil d’analytics ou déplacement de CDN peut imposer une modification de la politique et un nouveau test de validation. Il n’existe pas de durée de travail universelle et crédible pour cette tâche : il faut la mesurer sur ses propres missions.

Cloudflare propose deux façons de fournir la liste :

• allowedDomains est l’option directe ; elle accepte jusqu’à 50 motifs de noms d’hôte dans l’appel de lancement de la session.
• allowedDomainSets accepte jusqu’à quatre listes partagées. Il peut s’agir de l’ensemble common-cdns de Cloudflare ou d’URL HTTPS renvoyant une liste de noms d’hôte en texte brut.

Une liste partagée est pratique lorsque de nombreuses missions client utilisent les mêmes services approuvés. Elle obéit aussi à des règles de délai. Cloudflare peut mettre en cache une liste hébergée pendant une heure au maximum, et sa mise à jour ne touche que les sessions démarrées après la lecture de la liste actualisée. La politique d’une session en cours ne change jamais à son insu.

L’ensemble common-cdns implique un autre compromis : Cloudflare le maintient et peut le faire évoluer. On gagne du temps d’entretien, mais on ne dispose pas d’une liste d’autorisation immuable. Si un contrat ou un audit exige un ensemble stable de destinations, mieux vaut déclarer explicitement les noms d’hôte ou héberger sa propre liste.

Quatre équipes peuvent déjà en tirer parti

Une direction technique d’agence peut dissocier validation et contrôle

Autorisez l’application du client et ses dépendances indispensables, exécutez la tâche dans le navigateur, puis générez un lien Live View en lecture seule pour le responsable de compte ou la personne chargée de la validation côté client. Cette personne peut voir les éléments de preuve apparaître sans cliquer dans l’application ni altérer l’exécution. Le bénéfice : une étape de validation qui ne se transforme pas discrètement en transfert des commandes.

Un fondateur de SaaS peut garantir qu’un PDF autonome le reste

Si une capture d’écran ou un PDF est déjà généré à partir d’un HTML intégré et fiable, lancez la session avec un tableau allowedDomains vide et aucun ensemble de domaines. Le HTML continue de s’afficher, mais il ne peut récupérer ni API, ni script, ni image, ni police externe en HTTP ou HTTPS. On obtient alors une affirmation plus simple à vérifier : ce rendu n’a demandé aucun contenu web extérieur.

Ce contrôle précis n’est pas disponible dans Quick Actions, y compris pour les endpoints raccourcis souvent utilisés afin de produire des captures d’écran et des PDF. Il faut passer par une Browser Session avec Puppeteer, Playwright ou CDP.

Une équipe plateforme peut administrer une politique de dépendances unique

Hébergez une liste en texte brut sur HTTPS, placez un motif de nom d’hôte par ligne, puis référencez cette URL via allowedDomainSets. Plusieurs lanceurs de sessions peuvent ainsi partager la même liste. Le gain : un point d’administration unique, avec une règle essentielle à garder en tête — une seule ligne invalide entraîne le rejet de toute la liste hébergée.

Un auditeur sécurité peut exiger un test qui échoue

Ne vous contentez pas de montrer la configuration. Tentez une requête vers un nom d’hôte non autorisé, puis conservez le statut 403 et les deux en-têtes de garde-fou dans le dossier de validation. Vous prouvez ainsi que le chemin négatif fonctionne, au lieu de fournir la capture d’un objet dont la configuration semblait correcte.

Configurer une session protégée pour la validation

Ce guide est technique, car la fonctionnalité intervient dès la création de la session. Le code ci-dessous provient des pages Cloudflare consultées pour cet article.

1. 1

   Installer un client compatible et lier le navigateur

   Pour utiliser les garde-fous, Cloudflare exige @cloudflare/puppeteer 1.4.0 ou une version ultérieure. Voici sa commande d’installation de Puppeteer :

   npm i -D @cloudflare/puppeteer

   Votre Worker doit également disposer d’un binding de navigateur. Dans l’exemple Wrangler de Cloudflare, il s’appelle 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"
   	}
   }

   Vérifiez la version du paquet installé. L’ancienne présentation de Puppeteer indique encore la 1.1.0 comme version actuelle, alors que la page plus récente consacrée aux garde-fous exige la 1.4.0 ou une version ultérieure. C’est cette exigence fonctionnelle qu’il faut suivre.

2. 2

   Lancer la session avec une politique de destinations

   Dans l’exemple Puppeteer protégé de Cloudflare, le domaine racine, ses sous-domaines et l’ensemble partagé common-cdns sont autorisés :

   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;
   }

   Ne remplacez ces valeurs d’exemple qu’après avoir recensé les redirections, API, scripts, images et polices chargés par la page. Notez que *.example.com n’inclut pas example.com, d’où la présence des deux entrées.

3. 3

   Prouver qu’un hôte non approuvé est bloqué

   Envoyez une requête vers un nom d’hôte absent de la liste. Le résultat attendu est un statut HTTP 403 avec cf-mitigated: guardrails et cf-brapi-guardrails-reason: not-in-allowlist. Testez aussi la page autorisée sur l’intégralité de son parcours de connexion et de rendu. Le test négatif valide la frontière ; le test positif confirme que la tâche fonctionne encore.

4. 4

   Générer un lien de validation en lecture seule

   Une fois l’identifiant de session disponible, l’exemple REST de Cloudflare crée une vue d’onglet dans laquelle la personne invitée ne peut pas 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"
   		}
   	}'

   Générez cette URL dans un code serveur de confiance et transmettez-la par un canal de confiance. Par défaut, la connexion doit commencer dans les cinq minutes. La valeur expiresInMs peut être fixée entre 60,000 millisecondes au minimum et 3,600,000 millisecondes au maximum, soit une heure.

La répétition du mot guardrails peut prêter à confusion. Au lancement de la session, cet objet contient allowedDomains et contrôle les destinations. Lors de la demande d’URL Live View, il contient mode: readonly et régit cette personne. Les deux réglages sont nécessaires pour établir les deux périmètres.

La fonctionnalité peut faire basculer la tâche vers une autre facturation

La tarification actuelle de Browser Run de Cloudflare ne comporte aucune ligne distincte pour chaque entrée de la liste d’autorisation. Le coût évolue lorsque la méthode d’intégration change.

Quick Actions est facturé uniquement selon les heures de navigateur, mais ne peut pas utiliser ces garde-fous. Browser Sessions les prend en charge et facture à la fois les heures de navigateur et les navigateurs simultanés. Si un workflow de PDF ou de capture d’écran reposant sur un raccourci doit désormais restreindre les noms d’hôte, son passage à Puppeteer, Playwright ou CDP modifie donc l’implémentation comme le modèle de coût.

Avec Workers Paid, l’enveloppe incluse comprend 10 heures de navigateur par mois et 10 navigateurs simultanés. Le temps de navigateur supplémentaire coûte $0.09 par heure. La capacité simultanée supplémentaire coûte $2.00 par navigateur, sur la base de la moyenne mensuelle du pic quotidien.

La formule utile pour la planification est la suivante :

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

Dans son propre exemple, Cloudflare retient 50 heures de navigateur et une moyenne de 15 navigateurs simultanés. Le calcul donne $3.60 pour 40 heures supplémentaires, plus $10.00 pour cinq navigateurs supplémentaires, soit $13.60 de frais d’utilisation additionnels. Il ne s’agit pas d’un coût lié aux garde-fous, mais de la facture Browser Session correspondant au parcours qui les prend en charge.

Workers Free inclut 10 minutes de navigateur par jour et trois navigateurs simultanés. De quoi mener une petite preuve de concept, mais avec une marge limitée pour un workflow client soumis à plusieurs cycles de validation.

Si Browser Sessions fait déjà partie de la stack, les catégories de facturation ne changent pas. Le nouveau coût est surtout opérationnel : recenser les hôtes de ressources, tester les chemins bloqués et autorisés, puis maintenir la liste à jour. Pour comparer encore les différentes offres de navigateurs managés, le guide général des navigateurs pour agents IA replace ces postes d’utilisation dans leur contexte.

Les points de rupture à anticiper

Le cas le plus courant est une page qui fonctionne en développement, puis perd une police, une image, une redirection de connexion ou un appel d’API après l’activation de la liste d’autorisation. Un joker trop large peut masquer le problème tout en affaiblissant la frontière que l’on cherchait à créer.

Cloudflare autorise un joker par motif de nom d’hôte. Préférez *.example.com pour les sous-domaines et déclarez séparément le domaine racine. Un motif préfixé tel que *example.com peut aussi correspondre à un sosie comme evilexample.com : c’est donc un mauvais raccourci pour une politique client stricte.

Le mode lecture seule de Live View a sa propre limite. Il protège une connexion de visualisation donnée, pas la session contre son opérateur, ni contre le contrôle exercé par une autre connexion. Puppeteer et Playwright ne peuvent pas piloter la connexion en lecture seule, car les commandes nécessaires y sont bloquées. C’est utile pour un réviseur et inutilisable comme identifiant d’automatisation — exactement le comportement attendu.

Quick Actions et Kitesurf restent exclus de la fonctionnalité de garde-fous. Les équipes qui utilisent l’un ou l’autre ne sont pas concernées tant qu’elles ne jugent pas la restriction des noms d’hôte assez importante pour changer de méthode d’intégration.

Ce qu’il faut faire lundi

Choisissez une vraie mission client dont l’ensemble de destinations est stable. Ne commencez pas par votre parcours de connexion le plus complexe.

Recensez chaque nom d’hôte utilisé par le parcours qui aboutit, redirections et hôtes de ressources compris. Lancez une Browser Session protégée, vérifiez le résultat attendu, puis sollicitez volontairement un nom d’hôte non approuvé et conservez la preuve du statut 403. Enfin, donnez à un collègue un lien Live View en lecture seule et confirmez qu’il peut observer sans interagir.

Consignez quatre données pendant ce pilote : le nombre de noms d’hôte nécessaires, le temps consacré à leur maintenance, le nombre de requêtes légitimes bloquées lors du premier essai et le pic moyen de navigateurs simultanés. Ces quatre valeurs indiquent si ce garde-fou est un contrôle simple ou une promesse coûteuse pour le workflow concerné.

Passez à l’action cette semaine si vous livrez des tâches de navigateur à des clients, si les hôtes nécessaires peuvent être recensés et si observer sans contrôler répond à un véritable besoin de validation. Attendez si vos dépendances changent sans cesse, ou si votre tâche repose encore sur Quick Actions et que le coût du passage à Browser Session n’a pas été évalué. Si vous n’exécutez pas de Browser Sessions ou ne partagez pas de sessions de navigateur en direct, cette nouveauté ne changera rien à votre lundi.

Pour recevoir d’autres décryptages opérationnels des évolutions de plateformes, inscrivez-vous à la newsletter.