Connection Allowlists: файрвол внутри браузера

25 августа 2026 Chrome 152 вышел в стабильный канал, а вместе с ним — функция, которая перестраивает слой безопасности во фронтенде: Connection Allowlists. Идея прямая: один HTTP-заголовок ответа объявляет, куда странице разрешено обращаться, и браузер отклоняет всё остальное ещё до того, как соединение будет открыто.

Проблема: мы контролируем, что загружается, а не куда отправляется

Content Security Policy закрыла половину вопроса — откуда можно грузить скрипты, изображения и стили. Но она никогда не проектировалась под вторую половину, которая сегодня острее: когда скрипт уже выполняется на странице, куда он может отправить данные?

Именно в этом зазоре живут атаки на цепочку поставок. Одной отравленной зависимости в бандле не нужна ни XSS-дыра, ни вмешательство в DOM: достаточно fetch() на подконтрольный злоумышленнику домен, чтобы токены и содержимое форм тихо ушли наружу. За 2026 год этот сценарий повторялся не раз — см. npm-малварь, срабатывающую при import. Контроля над источником недостаточно, когда опасность — в точке назначения.

Что изменилось

Connection Allowlists переносят решение на сетевой уровень внутри браузера. Заголовок приходит вместе с ответом страницы и действует на каждое исходящее соединение:

http

Connection-Allowlist: (response-origin "https://api.example.com/*"
  "https://*.cdn.example"); report-to=network-reports

Синтаксис построен на Structured Fields (RFC 8941), а сопоставление адресов использует URLPattern вместо изобретения новой грамматики — то есть привычные правила матчинга путей работают здесь напрямую. Токен response-origin автоматически разрешает origin, отдавший ответ, так что прописывать его вручную не нужно.

Охват шире, чем подсказывает название: правило применяется к загрузке подресурсов, навигациям и редиректам, preload, preconnect и DNS prefetch, а также к WebSocket, WebRTC и WebTransport — в документах и в dedicated-, shared- и service-воркерах. Отклонённый запрос виден в DevTools со статусом blocked:other.

Перед включением запрета есть режим наблюдения — единственный реалистичный путь для работающего приложения:

http

Connection-Allowlist-Report-Only: (response-origin
  "https://api.example.com/*"); report-to=network-reports

Он собирает нарушения через Reporting API, ничего не ломая. Неделя наблюдения, разбор того, что на самом деле уходит со страницы (список обычно длиннее ожидаемого), и только потом — ужесточение.

Практические оговорки

Пока только Chrome. Функция прошла origin trial в версиях 148–151 и отгружена в 152 для desktop, Android и WebView. Mozilla и WebKit поддержку не заявили, обзор W3C TAG всё ещё в ожидании. Это дополнительный рубеж обороны, а не замена серверным ограничениям.
Это не лечение XSS. Область действия — точка назначения соединения, а не способ загрузки или исполнения ресурса. Инъекция остаётся инъекцией; новое в том, что канал выхода сужен.
Политики пересекаются, а не объединяются. Если применимо несколько политик, соединение проходит, только когда удовлетворяет всем — та же накопительная логика, что и в CSP.
Серверные редиректы всё ещё обсуждаются в спецификации, как и open redirects.
Список — живой документ. Новый инструмент аналитики или платёжный провайдер означает обновление заголовка, иначе функциональность сломается молча. Привяжите список к процессу деплоя, а не к чьей-то памяти.

Вывод

Модель, которую команды выстраивали через proxy и egress-правила на уровне инфраструктуры, теперь доступна внутри браузера одной строкой. Ценность не только в блокировке: впервые появляется явный записанный перечень того, с чем приложение реально соединяется. Начните с Report-Only и сделайте этот перечень частью код-ревью, а не аварийного регламента.

Первоисточник: Connection Allowlists на Chrome for Developers и спецификация в WICG.