Chrome 的本地网络访问 (LNA) 权限详解
你正在测试一个需要与本地 API 通信的 Web 应用,或者连接运行在 3000 端口的开发服务器,又或是网络中的硬件设备。Chrome 突然弹出一个对话框:“[网站] 想要查找并连接到本地网络上的任何设备。” 你完全没有预料到。下面我们将详细解释这到底是怎么回事以及为什么会发生。
核心要点
- Chrome 142 强制执行本地网络访问 (LNA) 权限,这是一个权限提示机制,用于阻止公共网站在未经授权的情况下访问本地网络设备。
- 从公共源向本地或环回地址发起的请求需要获得用户的明确同意。
- LNA 取代了早期的私有网络访问 (PNA) 方案,后者依赖于本地设备上不切实际的服务器端 CORS 预检请求。
- 开发者必须通过 HTTPS 提供页面,妥善处理权限被拒绝的情况,并使用权限策略 (Permissions Policy) 向 iframe 委派访问权限。
- 早期版本的 Chrome 在测试期间通过
chrome://flags/#local-network-access-check标志暴露了此行为。
什么是 Chrome 的本地网络访问权限?
Chrome 的本地网络访问 (LNA) 是一项浏览器安全变更,旨在防止公共网站在未经授权的情况下向本地网络设备发起请求。从 Chrome 142 开始,浏览器会通过明确的用户权限提示来控制这些请求。
在 LNA 之前,你访问的任何网站都可以将你的浏览器用作代理,悄悄探测你的路由器、打印机、本地 API 或网络上的任何其他设备——而你完全不知情。这是一个真实存在的攻击向量。恶意网站可以利用它对易受攻击的本地设备执行跨站请求伪造 (CSRF) 攻击,或者对你的网络拓扑进行指纹识别。
LNA 通过首先要求用户同意来填补这一安全漏洞。
这取代了早期称为私有网络访问 (PNA) 的尝试,后者依赖于服务器端 CORS 预检,要求本地设备明确选择加入。该方案陷入停滞,因为更新数百万台路由器和物联网设备的固件是不切实际的。LNA 将责任转移到网站上,而网站的更新要容易得多。
更多背景信息,请参阅 Chrome 官方关于本地网络访问限制的安全更新。
什么情况会触发 Chrome 本地网络访问权限提示?
当从公共源提供的页面尝试访问本地或环回目标地址时,会出现该提示。Chrome 定义了三种地址空间:
| 地址空间 | 示例 |
|---|---|
| 环回 (Loopback) | 127.0.0.0/8, ::1 |
| 本地 (Local) | 192.168.x.x, 10.x.x.x, 172.16.0.0–172.31.255.255, .local 域名, fc00::/7 |
| 公共 (Public) | 其他所有地址 |
任何从公共 → 本地或公共 → 环回的跨空间请求都会触发 LNA。开发者遇到的常见场景包括:
- 托管的 Web 应用调用
http://192.168.1.1/api - 云端仪表板连接到本地运行在
localhost:8080的代理程序 - 设备设置页面(从制造商的公共网站提供)与局域网上的硬件通信
- ZTNA 或 VPN 解决方案通过 Chrome 归类为本地的 IPv6 范围(如
fc00::/7)路由流量
Discover how at OpenReplay.com.
开发者需要了解的关键约束
仅限安全上下文。 LNA 权限只能从 HTTPS 页面请求。然而,由于本地设备通常无法提供 HTTPS,Chrome 可能会在授予权限后对明确的本地目标放宽混合内容限制,因为许多设备只暴露 HTTP 端点。
// Chrome 知道这是本地地址 — 混合内容检查豁免
fetch("http://192.168.0.1/ping");
// Chrome 通过注解知道这是本地地址
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });
// Chrome 在 DNS 解析之前不知道这是本地地址 — 不豁免
fetch("http://example.com/ping");
Worker 需要特殊处理。 Service Worker 和 Shared Worker 需要父源已经获得 LNA 权限,才能发起本地网络请求。Worker 无法直接触发权限提示。
iframe 需要权限委派。 嵌入的 iframe 需要通过权限策略 (Permissions Policy)(local-network-access)进行明确的权限委派,才能发起本地网络请求。
WebTransport 和 WebRTC 尚未被 LNA 控制覆盖——预计在未来的 Chrome 版本中会支持。WebSocket 到本地地址的连接遵循与其他网络请求相同的本地网络访问限制。
为什么这比看起来更重要
Chrome 的本地网络安全变更使浏览器与 iOS、Android 和 macOS 多年来在操作系统层面所做的事情保持一致。这些平台上的应用已经会请求本地网络访问权限。Chrome 正在迎头赶上。
对于需要从浏览器访问本地设备的开发者——无论是开发服务器、硬件接口还是本地代理——实际影响是明确的:你的应用现在需要有意触发权限提示,处理用户拒绝的情况,并确保请求源自安全上下文。
结论
Chrome 的本地网络访问权限是浏览器处理公共网络与私有网络边界方式的重大转变。对于最终用户来说,它填补了一个长期存在的盲点。对于开发者来说,它引入了一个新要求:任何访问本地地址空间的公共源页面现在都必须考虑明确的权限控制。
调整过程很简单。通过 HTTPS 提供页面,在 UI 中预见权限被拒绝的情况,通过权限策略向 iframe 委派访问权限,并尽早测试。将 chrome://flags/#local-network-access-check 设置为 “Enabled (Blocking)” 以准确了解 Chrome 142 用户将体验到的情况。你越早适应,用户遇到的意外就越少。
常见问题
如果你从 localhost 提供应用并向 localhost 发起请求,两个端点都在环回地址空间中。Chrome 不会为同一空间的请求触发 LNA 提示。该提示仅在公共源尝试访问本地或环回目标时出现。本地到本地的开发工作流程不受影响。
本地网络请求会被阻止,fetch 调用会以网络错误拒绝。你的应用应该捕获此失败并显示有意义的消息,解释需要本地网络访问权限。如果用户改变主意,可以稍后通过 Chrome 网站设置更改权限。
可以。Chrome 提供企业策略,管理员可以使用这些策略将特定源加入白名单,或在托管设备上完全禁用 LNA 检查。这对于内部工具和信息亭设置很有用,在这些场景中权限提示会中断工作流程。
浏览器扩展在不同的安全模型下运行,不受 LNA 权限提示的约束。具有适当主机权限的扩展仍然可以向本地网络地址发起请求,而不会触发对话框。只有常规网页上下文受 LNA 控制。
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.