[Bug]: Playwright 1.56 no longer sends Origin header, breaking CORS-dependent requests

[arturpopichenko]

Version

1.56

Steps to reproduce

After upgrading Playwright from 1.55 → 1.56, several UI tests started failing.

In Playwright 1.55, the browser automatically included the Origin header in network requests, which matched our backend CORS configuration.
Starting from 1.56, this header is no longer sent — as a result, the backend now rejects the requests (CORS preflight fails, or the request is treated as unauthenticated).

Expected behavior

The Origin header should be preserved in requests, or at least there should be a configuration option to enable/disable this behavior.

Actual behavior

Requests no longer include Origin ( and also
sec-fetch-mode: cors
sec-fetch-site: cross-site )
, causing the backend to block or reject them.

Additional context

request headers are missed:

Origin
sec-fetch-mode: cors
sec-fetch-site: cross-site

Environment

OS: MacOS
Playwright: "@playwright/test": "1.56.0"

[Skn0tt]

Hmm, that's an unexpected change. Since you're the first to report this, I doubt it's widespread because this would break almost everybody. Could you provide me with a reproduction case, as explained in the issue template?

[Mathias-S]

Hi, just chiming in that we are also having problems with CORS preflight requests in Playwright 1.56. The CORS preflight works as expected in Playwright 1.55.

However, the issue is possibly slightly different: we are getting CORS errors on the preflight requests themselves, so the OPTIONS requests seem to get blocked. The server never receives the OPTIONS requests. But we are using a reverse proxy and it's possible that if the OPTIONS request is missing headers, then the request might get dropped before it reaches the server. This is in a private enterprise app; I haven't been able to create a minimal reproduction yet, but I can try.

This is what the row looks like in Devtools:

Edit: We were sending Fetch calls from a public website to a website on an internal network ("local website"), which is what was blocked beginning with Chrome 142, see https://chromestatus.com/feature/5152728072060928

The fix mentioned below, using context.grantPermissions(['local-network-access']);, in Playwright 1.56.1, worked as a temporary workaround.

[Skn0tt]

If you could provide a minimal reproduction, that'd be great. If that's hard to do, you could also try bisecting through the nightly Playwright versions: https://www.npmjs.com/package/playwright?activeTab=versions
If we know what day this behaviour change ocurred, then we've got it down to a few commits.

Also, are you seeing this occur on all browsers or only on one?

[jgoz]

We are also seeing this issue but only when running our tests in a custom Docker container.

FROM node:24-bookworm-slim

RUN npx playwright install --with-deps chromium --only-shell

CMD ["sh", "-c", "npx playwright test"]

(trimmed down for brevity)

I can try to help with a bisect too.

[jgoz]

OK, I have narrowed this down. It was working up to and including 1.56.0-alpha-2025-09-11, but stopped working in 1.56.0-alpha-2025-09-12 and later. This corresponds to chromium 141.0.7390.7 and 141.0.7390.16, respectively.

Some of our engineers happened to see the exact same CORS issues today when using Arc with Chromium 141.0.7390.55, which is completely unrelated to Playwright. Their solution was to modify the site settings and set "Local network access" to "Allow".

[arturpopichenko]

@Skn0tt
I tried several versions:

Can reproduce:

chromium | 1.56.0-beta-1759861168000 | headless true and false
chromium | 1.56.0-beta-1759527268000 | headless true and false
chromium | 1.56.0-beta-1759412259000 | headless true and false
chromium | 1.56.0-alpha-2025-09-29 | headless false
chromium | 1.56.0-alpha-1758750661000| headless false

Cannot reproduce (Origin header is present):

chromium | 1.55.1 | headless false
firefox | 1.56.0-beta-1759861168000 | headless false
webkit | 1.56.0-beta-1759861168000 | headless true and false

Conclusion:
The Playwright 1.56 with firefox and webkit looks ok.
It looks like Chromium + Playwright 1.55.1 is the last version that still includes the Origin header.
Unfortunately, I’m not able to provide a minimal repro project in the next couple of days.

[Skn0tt]

What @jgoz reports sounds like a behaviour change in Chromium. The changelog in Chromium doesn't mention this, we should file this as a bug report on https://crbug.com/. @jgoz could you file the bug report? I can also do it, but since your team is able to reproduce you can be much more helpful.

[jgoz]

OK, did some more digging and I'm not sure if my issue is related to the original report. We are seeing the following error message in our dev environment, both in Playwright and directly in browsers, due to Local Network Access prompts:

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.

The dev environment is only accessible via a VPN and internal-auth-system resolves to a 10.* IP address, which Chrome treats as non-public. Since the new default behavior is to block local network access, fetch() calls to retrieve the OAuth metadata fail.

We should be able to address this via playwright config by setting the local-network-access permission, but Playwright doesn't recognize this as a valid permission. Should I file a separate issue for that?

[Skn0tt]

Yes, please file a separate issue for that.

[alexander-vershinin]

We're also reproducing this problem while updating from 1.54.2 to 1.56.0 version.

[yury-s]

@arturpopichenko any chance you can share a repro?

[arturpopichenko]

@yury-s I was unable to reproduce this publicly. Origin behaviour depends on specific CORS conditions of the private page, so an identical repro on a public site isn’t possible

[yury-s]

@arturpopichenko can you check then if it's the same issue as described in #37861 and you can work around it by passing --ip-address-space-overrides=... argument to Chromium?

[yury-s]

@arturpopichenko and other who experience this issue, please update to 1.56.1 and try setting the new permission await context.grantPermissions(['local-network-access']);. Since we don't have repros, our hypothesis is that you it is the effect of Local Network Access prompts recently enabled in Chromium. The feature will block requests to local network resources from a public origin and Chrome teams' recommendation is to grant the permission in the development environment, see #37861 for more details. Please let us know if it helps.