Accept local-network-access permission

[jgoz]

Originally posted in #37769

Starting with Chrome 141.0.7390.16 (Playwright 1.56.0-alpha-2025-09-12), we are experiencing CORS issues like the following:

Access to fetch at 'https://<internal-auth-system>/.well-known/openid-configuration' from
origin 'https://<dev-application>/' has been blocked by CORS policy: Permission was denied for
this request to access the `unknown` address space.

This is not a Playwright issue, rather, it is a new Chrome feature called Local Network Access prompts. In addition to our test execution failures on 1.56.0, some of our engineers also began seeing these issues in chromium-based browsers that enabled LNA by default.

The reason we are seeing these both in our dev environment and during Playwright test execution is because our internal-auth-system is behind a VPN and resolves to a 10.* IP address, which Chrome-with-LNA treats as non-public. A human user would get prompted to allow this network access, but the test execution treats it as a Deny and fetch() calls to retrieve the OAuth metadata fail.

According to the LNA Adoption Guide, automated test environments can preemptively set a local-network-access permission to allow local network access, but when I try to configure this in Playwright, it rejects the permission as invalid. I'm uncertain whether this rejection originates in Playwright or in Chromium, though.

Options to support LNA

1. Playwright accepts local-network-access permission
2. Browser launch args include --ip-address-space-overrides=10.1.2.3:0=public to treat specific endpoints as public — this is quite inconvenient because addresses must be specified individually (no wildcard support), which means pre-resolving all possible addresses in Playwright Config and dynamically generating the arguments for the current environment
3. Modify all participating servers to include Content-Security-Policy: treat-as-public-address as a blanket response header in non-public environments. We will likely pursue this path in order to solve for human and automated users.

I'll file separate issues in Chromium related to this, but in the event that the Playwright team can support Option 1 above (Playwright accepts local-network-access permission), that would be a great option to have.

[yury-s]

According to the LNA Adoption Guide, automated test environments can preemptively set a local-network-access permission to allow local network access, but when I try to configure this in Playwright, it rejects the permission as invalid. I'm uncertain whether this rejection originates in Playwright or in Chromium, though.

If the error is Unknown permission: local-network-access, it likely comes from Playwright as we have explicit mapping of the supported permissions. We normally don't add experimental Chrome stuff there, but I can see how annoying it could be.

This "permission prompt for Local Network Access" is an experimental opt-in feature, why can't you run the tests in a browser with the default configuration where the feature is disabled?

[jgoz]

@yury-s

This "permission prompt for Local Network Access" is an experimental opt-in feature, why can't you run the tests in a browser with the default configuration where the feature is disabled?

According to an update in the original launch article, this will not be experimental or opt-in for long:

Update (2025-09-29): The Local Network Access permission prompt is launching in Chrome 142. We've written an LNA adoption guide to answer frequently asked questions.

But we already observed this behavior in the version of chromium shipping with Playwright 1.56.0. Per my comment in another issue, this behavior was exhibited starting in Playwright 1.56.0-alpha-2025-09-12 (chromium 141.0.7390.16). And we did nothing to toggle the behavior on — we simply upgraded Playwright and started observing these errors.

[jgoz]

For some added context here, our dev environment is a mix of public and private address spaces because our root URL is behind CloudFront, while the rest of our services are private. We did this for infrastructure consistency between dev/staging/prod.

After reading more about LNA, I think people with more conventional private/dev environments should be unaffected because the prompt only triggers when there is a mix of public and private address spaces.

[yury-s]

But we already observed this behavior in the version of chromium shipping with Playwright 1.56.0. Per my #37769 (comment), this behavior was exhibited starting in Playwright 1.56.0-alpha-2025-09-12 (chromium 141.0.7390.16). And we did nothing to toggle the behavior on — we simply upgraded Playwright and started observing these errors.

I've been trying to reproduce the issue with 1.56.0-alpha-2025-09-12 but the feature seems to be disabled and all simple tests with cors requests from a public origin to the local networked went through. There must be something that is different in your environment. It'd be really helpful if you could extract a minimal repro.

[jgoz]

@yury-s I put together a repro here: https://github.com/jgoz/pw-lna-repro

Note that the test is constructed to pass, but it is expecting a failure due to the permission being absent. It is using the latest Playwright release 1.56.0. You'll need python3 to be installed for running the local test server.

This is all based on Google's test site: https://lna-testing.notyetsecure.com/

[yury-s]

The new permission is available in 1.56.1, please give it a try.

[jgoz]

Upgrading to 1.56.1 and adding local-network-access solves our issue. Thank you!