Chrome Security Policy Complicates Debugging

- The Local Network Access (LNA) policy is a direct response to longstanding security vulnerabilities, specifically Cross-Site Request Forgery (CSRF) attacks. Malicious websites have historically used users' browsers as proxies to send requests to private network devices like routers, a threat that has impacted hundreds of thousands of users. - This security model evolved from an earlier proposal called Private Network Access (PNA), which planned to use CORS preflight requests with new headers like `Access-Control-Request-Private-Network`. That rollout was put on hold due to developer feedback and compatibility issues, leading to the current approach. - Starting with Chrome 142, the browser now gates access to local network resources, including `localhost`, behind a user permission prompt. This change can block requests before a local development server's CORS headers are even evaluated, a key source of confusion for developers. - The restrictions particularly affect applications running within sandboxed iframes, which are common in development environments for platforms like Microsoft Teams or Power Apps. For a local resource to be fetched from within an iframe, the parent frame must now explicitly delegate permission using the `allow="local-network-access"` attribute. - For enterprise environments, administrators have policy controls to manage this behavior. They can use `LocalNetworkAccessAllowedForUrls` to pre-approve trusted sites and suppress the permission prompt for users, maintaining a smoother workflow for internal tools. - The specification continues to evolve with more granular controls planned. Chrome 145 is slated to split the single `local-network-access` permission into two distinct permissions: `local-network` for internal IPs and `loopback-network` specifically for `localhost`.