Автоматизация браузера в Cloudflare: контроль хостов

14 сентября 2026 года в Cloudflare Browser Run появились два механизма, которые меняют то, как клиенту передаётся автоматизация браузера: сессию можно ограничить списком разрешённых имён хостов, а ревьюер может наблюдать за ней через Live View без права управления. Напрямую разрешается указать до 50 имён хостов или подключить до четырёх общих наборов доменов, однако главное здесь не размер списка, а чёткая рабочая граница.

Две независимые границы вместо одной

Сессия Browser Run — это удалённый экземпляр Chrome. Код управляет им через Puppeteer, Playwright или Chrome DevTools Protocol, который обычно сокращают до CDP.

Новые ограничения сессии определяют, к каким конечным хостам браузер может обращаться по HTTP или HTTPS. Политика задаётся при запуске сессии и действует до её завершения.

Новый режим Live View только для просмотра решает другую задачу. Он определяет возможности одного человека, который открыл одну сгенерированную ссылку. Такой зритель видит сессию, но не может переходить по страницам, вводить текст, нажимать элементы или выполнять JavaScript.

Это принципиальное различие. Автоматизация по-прежнему управляет браузером, а ревьюер лишь наблюдает. При этом HTTP- и HTTPS-запросы браузера остаются в рамках списка разрешённых хостов сессии независимо от того, какое подключение Live View открыто.

Как автоматизация браузера становится процессом клиентского ревью

Представим агентство, которое формирует отчёт в веб-приложении клиента. Браузеру нужны основной хост клиента, хост аутентификации, API, хост шрифтов и, возможно, CDN изображений. Клиент также хочет увидеть ход выполнения до того, как утвердит результат.

Теперь эти вопросы можно решать независимо:

1. Технический руководитель утверждает адреса, необходимые сессии.
2. Клиент получает URL Live View только для просмотра и наблюдает за выполнением задачи.

Ревьюер не получает интерактивный браузер, а задаче не открывается доступ ко всем адресам. Это более чистая передача на проверку, чем ситуация, когда одна общая ссылка на браузер одновременно служит средством демонстрации и решением по управлению доступом.

Однако полноценной системой безопасности эта схема не становится. В документации Cloudflare речь идёт об управлении именами хостов для HTTP- и HTTPS-запросов, поэтому называть механизм сетевой песочницей общего назначения не стоит. URL Live View также содержит подписанный JWT, а значит, полная ссылка является учётными данными. Режим только для просмотра исключает взаимодействие, но всё равно показывает содержимое страницы.

Главная работа — поддерживать белый список доменов

Самого очевидного имени хоста почти никогда не хватает для всей страницы.

Рабочая страница может перенаправлять пользователя при входе, обращаться к отдельному API, загружать скрипты с одного хоста, изображения — с другого, а шрифты — с третьего. Cloudflare требует включить в список все эти зависимости. Если пропустить хотя бы одну, браузер получит для соответствующего запроса ошибку 403, а в заголовках ответа появятся cf-mitigated: guardrails и cf-brapi-guardrails-reason: not-in-allowlist.

Поэтому ведение списка разрешений становится реальной статьёй затрат при сдаче проекта. Редизайн у клиента, смена провайдера идентификации, системы аналитики или CDN могут потребовать изменения политики и нового проверочного запуска. Универсальной и честной оценки трудозатрат здесь нет — её нужно измерять на собственных задачах.

Cloudflare предлагает два способа передать список:

• allowedDomains — прямой вариант: до 50 шаблонов имён хостов в запросе на запуск сессии.
• allowedDomainSets — до четырёх общих списков. Это может быть набор Cloudflare common-cdns или HTTPS-адреса, возвращающие обычный текстовый список имён хостов.

Общий список удобен, когда многим клиентским задачам требуются одни и те же разрешённые сервисы. Но у него есть правила обновления. Cloudflare кеширует размещённый список на срок до одного часа, а изменения затрагивают только те сессии, которые запущены после чтения обновлённого списка. Политика уже работающей сессии никогда не меняется на ходу.

У common-cdns есть ещё один компромисс: список поддерживает Cloudflare и со временем может его менять. Это сокращает работу по сопровождению, но такой список разрешений нельзя считать фиксированным. Если договор или аудит требует неизменного набора адресов, перечислите хосты явно либо разместите собственный список.

Четыре команды, которым это пригодится уже сейчас

Технический руководитель агентства отделит согласование от управления

Разрешите приложение клиента и его обязательные зависимости, запустите браузерную задачу, а затем создайте ссылку Live View только для просмотра для аккаунт-менеджера или ревьюера со стороны клиента. Они увидят, как появляются подтверждения результата, но не смогут нажимать элементы приложения или менять ход выполнения. В итоге этап проверки не превращается незаметно в передачу операторского доступа.

Основатель SaaS сохранит PDF полностью автономным

Если скриншот или PDF уже создаётся из доверенного встроенного HTML, запустите сессию с пустым массивом allowedDomains и без наборов доменов. HTML отобразится, но не сможет загрузить по HTTP или HTTPS внешний API, скрипт, изображение или шрифт. Результат можно сформулировать просто и проверить: при этом рендеринге не запрашивался внешний веб-контент.

Этот механизм недоступен в Quick Actions, включая упрощённые эндпоинты, которые часто используют для скриншотов и PDF. Потребуется Browser Session через Puppeteer, Playwright или CDP.

Платформенная команда получит единую политику зависимостей

Разместите по HTTPS обычный текстовый список, по одному шаблону имени хоста в каждой строке, и укажите его URL через allowedDomainSets. Один список смогут использовать несколько компонентов, запускающих сессии. Преимущество — единая точка сопровождения; важное условие — одна некорректная строка приводит к отклонению всего размещённого списка.

Специалист по безопасности потребует негативный тест

Не ограничивайтесь демонстрацией конфигурации. Выполните запрос к хосту, которого нет в списке разрешённых, а затем сохраните статус 403 и два заголовка ограничений вместе с материалами проверки. Это подтвердит, что негативный сценарий действительно сработал, а не просто покажет скриншот объекта с правдоподобными настройками.

Как настроить защищённую сессию для ревью

Ниже — техническая инструкция, поскольку механизм задаётся при создании сессии. Код взят со страниц Cloudflare, изученных для этой статьи.

1. 1

   Установите совместимый клиент и добавьте привязку браузера

   Для работы ограничений Cloudflare требует @cloudflare/puppeteer версии 1.4.0 или новее. Команда установки Puppeteer выглядит так:

   npm i -D @cloudflare/puppeteer

   В Worker также нужно добавить привязку браузера. В примере Cloudflare для Wrangler она называется 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"
   	}
   }

   Проверьте версию установленного пакета. В старом обзоре Puppeteer текущей всё ещё названа версия 1.1.0, но на более новой странице ограничений указано требование 1.4.0 или новее. Ориентируйтесь на требование конкретной функции.

2. 2

   Запустите сессию с политикой конечных адресов

   В примере Cloudflare для защищённого Puppeteer разрешены корневой домен, его поддомены и общий набор 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;
   }

   Заменяйте значения из примера только после того, как учтёте все перенаправления, API, скрипты, изображения и шрифты страницы. Обратите внимание: *.example.com не включает example.com, поэтому в списке нужны обе записи.

3. 3

   Докажите, что неразрешённый хост блокируется

   Отправьте запрос к хосту за пределами списка. Ожидаемый результат — HTTP 403 с заголовками cf-mitigated: guardrails и cf-brapi-guardrails-reason: not-in-allowlist. Также проверьте разрешённую страницу на всём пути от входа до рендеринга. Негативный тест подтверждает работу границы, а позитивный — что задача по-прежнему выполняется.

4. 4

   Создайте ссылку на ревью только для просмотра

   Когда идентификатор сессии уже известен, REST-пример Cloudflare создаёт представление вкладки, с которым зритель не может взаимодействовать:

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

   Создавайте этот URL в доверенном серверном коде и передавайте по доверенному каналу. По умолчанию подключение нужно начать в течение пяти минут. Параметр expiresInMs можно задать от 60,000 до 3,600,000 миллисекунд, то есть максимум до одного часа.

Повторение слова guardrails может сбить с толку. При запуске сессии внутри него находится allowedDomains, и эта настройка управляет конечными адресами. В запросе URL Live View внутри него находится mode: readonly, и здесь настройка управляет возможностями зрителя. Чтобы получить обе границы, нужны обе настройки.

Функция может перевести задачу на другую модель оплаты

В актуальных тарифах Browser Run Cloudflare нет отдельной платы за каждую запись в списке разрешений. Расходы меняются при смене способа интеграции.

В Quick Actions оплачиваются только часы работы браузера, но эти ограничения там недоступны. Browser Sessions поддерживают ограничения, а в счёт входят и часы работы браузера, и число одновременно работающих браузеров. Если процесс создания PDF или скриншота через сокращённую конечную точку теперь требует ограничения по именам хостов, переход на Puppeteer, Playwright или CDP изменит как реализацию, так и модель затрат.

Тариф Workers Paid включает 10 часов работы браузера в месяц и 10 одновременно работающих браузеров. Дополнительное время стоит $0.09 в час. Каждый дополнительный одновременно работающий браузер стоит $2.00, а расчёт основан на среднем за месяц значении ежедневного пика.

Для планирования пригодится формула:

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

В примере самой Cloudflare используются 50 часов работы браузера и в среднем 15 одновременно работающих браузеров. Получается $3.60 за 40 дополнительных часов плюс $10.00 за пять дополнительных браузеров — итого $13.60 сверх включённого объёма. Это не плата за ограничения, а счёт за Browser Session, то есть за способ интеграции, который их поддерживает.

В Workers Free включены 10 минут работы браузера в день и три одновременно работающих браузера. Для небольшой проверки этого может хватить, но для клиентского процесса с повторными ревью запаса немного.

Если Browser Sessions уже используются, категории оплаты не меняются. Новые затраты в основном операционные: собрать список хостов ресурсов, проверить разрешённые и заблокированные сценарии и поддерживать список в актуальном состоянии. Если выбор управляемого браузера ещё продолжается, более широкий гид по браузерам для ИИ-агентов поможет сопоставить эти статьи расхода.

Где решение по-прежнему даёт сбой

Самый простой сценарий отказа: страница работает при разработке, а после включения списка разрешений теряет шрифт, изображение, перенаправление при входе или запрос к API. Слишком широкий подстановочный шаблон может скрыть проблему, одновременно ослабив ту границу, ради которой всё настраивалось.

Cloudflare допускает один подстановочный знак на шаблон имени хоста. Для поддоменов лучше использовать *.example.com, а корневой домен указывать отдельно. Шаблон с префиксом, например *example.com, может совпасть и с похожим адресом вроде evilexample.com, поэтому для строгой клиентской политики это плохое сокращение.

У Live View только для просмотра есть собственное ограничение. Такой режим защищает одно подключение зрителя, но не сессию от её оператора и не другое подключение от управления. Puppeteer и Playwright не могут работать через подключение только для просмотра, поскольку необходимые команды заблокированы. Для ревьюера это полезно, а в качестве учётных данных автоматизации — бесполезно, как и должно быть.

Quick Actions и Kitesurf по-прежнему не поддерживают ограничения. Для команд, использующих любой из этих вариантов, ничего не изменится, пока они не решат, что граница по именам хостов оправдывает смену способа интеграции.

Что сделать в понедельник

Выберите одну реальную клиентскую задачу со стабильным набором конечных адресов. Не начинайте с самого запутанного сценария входа.

Составьте перечень всех имён хостов на успешном пути, включая перенаправления и хосты ресурсов. Запустите защищённую Browser Session, проверьте нужный результат, затем намеренно обратитесь к одному неразрешённому хосту и сохраните подтверждение ошибки 403. В завершение дайте коллеге ссылку Live View только для просмотра и убедитесь, что он может наблюдать, но не взаимодействовать.

Зафиксируйте по итогам пилота четыре показателя: количество необходимых имён хостов, время на поддержку списка, число корректных запросов, которые сначала оказались заблокированы, и средний пик одновременно работающих браузеров. Эти значения покажут, станет ли механизм понятным средством контроля или дорогим обещанием для конкретного процесса.

Действовать стоит уже на этой неделе, если браузерные задачи передаются клиентам, нужные хосты можно заранее определить, а наблюдение без управления решает реальную задачу согласования. Лучше подождать, если зависимости постоянно меняются либо процесс всё ещё работает на Quick Actions, а стоимость перехода на Browser Session ещё не рассчитана. Если Browser Sessions не используются и доступом к работающему браузеру никто не делится, этот релиз не меняет планы на понедельник.

Если нужны другие разборы обновлений платформ с точки зрения эксплуатации, подпишитесь на рассылку.