v145 · security

Local network access restrictions

Requests from public sites to local IP addresses (and from local sites to loopback) now require a permission prompt. Mitigates cross-site request forgery attacks against intranet routers, IoT devices, and dev servers running on the user's machine.

concepts

  1. Request Classifier

    Type a target URL and see whether Chrome would classify the resulting request as "local network access" and gate it behind a prompt. Helpful for dev teams instrumenting their own deployments.

  2. targetAddressSpace fetch option

    The Chrome 145 spec dropped CORS preflights in favour of a permission prompt — but developers must declare intent via the new targetAddressSpace fetch() option. Pick a target + a value, fire the request, see what happens.

  3. Split permission probe

    Chrome 145 split one permission into two: loopback-network (developer tools) and local-network (IoT/router/LAN). Probe both via the Permissions API and see why minimum-privilege matters.

  4. CSRF Scenario

    Step through three animated scenarios: a CSRF attack against a home router without LNA, the same attack blocked by Chrome 145, and a legitimate dev tool that opts in via targetAddressSpace. See exactly which requests Chrome allows, prompts, or blocks.

why it shipped

The classic CSRF attack against a home router goes: visit attacker.example, attacker.example fetches http://192.168.1.1/admin?action=... via your browser, your browser sends your authenticated session cookies along, the router does what the attacker asked. The local network access restriction puts a permission prompt between any public-origin page and any private-IP target. Routers and devices that explicitly opt in via CORS preflights keep working; the bulk of attack surface goes away.

references