Разрешение Local Network Access (LNA) в Chrome: подробное объяснение

Вы тестируете веб-приложение, которое обращается к локальному API, dev-серверу на порту 3000 или аппаратному устройству в вашей сети. Chrome внезапно показывает диалоговое окно: “[Сайт] хочет найти и подключиться к любому устройству в вашей локальной сети”. Вы этого не ожидали. Вот что именно происходит и почему.

Что такое разрешение Local Network Access в Chrome?

Local Network Access (LNA) в Chrome — это изменение в безопасности браузера, которое предотвращает возможность публичных веб-сайтов незаметно выполнять запросы к устройствам в вашей локальной сети. Начиная с Chrome 142, браузер ограничивает такие запросы явным запросом разрешения у пользователя.

До появления LNA любой посещённый вами веб-сайт мог использовать ваш браузер как прокси для скрытого сканирования вашего роутера, принтера, локального API или любого другого устройства в сети — без вашего ведома. Это реальный вектор атаки. Вредоносный сайт мог использовать это для выполнения межсайтовой подделки запроса (CSRF) против уязвимых локальных устройств или для снятия отпечатка топологии вашей сети.

LNA закрывает эту брешь, требуя сначала согласия пользователя.

Это заменяет более раннюю попытку под названием Private Network Access (PNA), которая полагалась на server-side CORS preflight-запросы и требовала явного согласия от локальных устройств. Этот подход застопорился, потому что обновление прошивки на миллионах роутеров и IoT-устройств непрактично. LNA переносит ответственность на веб-сайты, которые гораздо легче обновить.

Для получения дополнительной информации см. официальное обновление безопасности Chrome о Local Network Access restrictions.

Что вызывает запрос разрешения Chrome Local Network Access?

Запрос появляется, когда страница, обслуживаемая с публичного источника, пытается обратиться к локальному адресу или loopback-адресу. Chrome определяет три адресных пространства:

Любой запрос, пересекающий границу public → local или public → loopback, вызывает LNA. Типичные сценарии разработчиков, которые с этим сталкиваются:

• Размещённое веб-приложение, вызывающее http://192.168.1.1/api
• Облачная панель управления, подключающаяся к локально запущенному агенту на localhost:8080
• Страница настройки устройства (обслуживаемая с публичного сайта производителя), взаимодействующая с оборудованием в вашей LAN
• ZTNA или VPN-решение, маршрутизирующее трафик через IPv6-диапазоны, которые Chrome классифицирует как локальные (например, fc00::/7)

Ключевые ограничения, которые нужно знать разработчикам

Только безопасные контексты. Разрешение LNA может быть запрошено только со страниц HTTPS. Однако, поскольку локальные устройства часто не могут обслуживать HTTPS, Chrome может смягчить ограничения на смешанный контент для явно локальных целей после предоставления разрешения, так как многие устройства предоставляют только HTTP-endpoints.

// Chrome знает, что это локальный адрес — проверка смешанного контента пропущена
fetch("http://192.168.0.1/ping");

// Chrome знает, что это локальный адрес через аннотацию
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome НЕ знает, что это локальный адрес до разрешения DNS — не освобождается от проверки
fetch("http://example.com/ping");

Workers требуют специальной обработки. Service Workers и Shared Workers требуют, чтобы родительский источник уже получил разрешение LNA, прежде чем они смогут выполнять запросы к локальной сети. Worker не может напрямую вызвать запрос разрешения.

Iframe-элементы требуют делегирования. Встроенные фреймы нуждаются в явном делегировании разрешения через Permissions Policy (local-network-access) для выполнения запросов к локальной сети.

WebTransport и WebRTC пока не охвачены ограничениями LNA — поддержка ожидается в будущих релизах Chrome. WebSocket-соединения с локальными адресами следуют тем же ограничениям доступа к локальной сети, что и другие сетевые запросы.

Почему это важнее, чем кажется

Изменение безопасности локальной сети в Chrome приводит браузер в соответствие с тем, что iOS, Android и macOS делают уже много лет на уровне ОС. Приложения на этих платформах уже запрашивают доступ к локальной сети. Chrome догоняет.

Для разработчиков, обращающихся к локальным устройствам из браузера — будь то dev-сервер, аппаратный интерфейс или локальный агент — практическое влияние очевидно: ваше приложение теперь должно намеренно вызывать запрос разрешения, обрабатывать случай отказа пользователя и обеспечивать, чтобы запросы исходили из безопасного контекста.

Заключение

Разрешение Local Network Access в Chrome — это значимый сдвиг в том, как браузеры обрабатывают границу между публичным интернетом и вашей частной сетью. Для конечных пользователей это закрывает давнюю слепую зону. Для разработчиков это вводит новое требование: любая страница с публичного источника, которая обращается к локальному адресному пространству, теперь должна учитывать явный запрос разрешения.

Адаптация проста. Обслуживайте свои страницы через HTTPS, предусматривайте отказы в разрешении в вашем UI, делегируйте доступ iframe-элементам через Permissions Policy и тестируйте заранее. Используйте chrome://flags/#local-network-access-check со значением “Enabled (Blocking)”, чтобы увидеть, что именно будут испытывать пользователи Chrome 142. Чем раньше вы адаптируетесь, тем меньше сюрпризов столкнутся ваши пользователи.

Часто задаваемые вопросы

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.