Access CORS preflight fails with 403 even when

Not specified by the original author.

TL;DR

If your frontend behind Cloudflare Access fails CORS preflight with 403, go to Zero Trust, Access controls, Applications, open the app, then Advanced settings and CORS settings, and enable Bypass options requests to origin.

Steps

1. If your frontend behind Cloudflare Access fails CORS preflight with 403, go to Zero Trust, Access controls, Applications, open the app, then Advanced settings and CORS settings, and enable Bypass options requests to origin. Make sure your origin enforces the Access JWT on the real requests, since Access no longer guards OPTIONS. Alternatives are having Cloudflare respond to the preflight, or a Worker that injects the auth token when both sides are behind Access.

When to use

You are seeing this: Make sure your origin enforces the Access JWT on the real requests, since Access no longer guards OPTIONS. Use this skill when you run into "Access CORS preflight fails with 403 even when you are logged in".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (CORS, Cloudflare One): documents a gotcha that trips agents putting a browser app behind Cloudflare Access. A preflighted cross-origin request gets a 403 on the OPTIONS call even when the user is logged in, because browsers never include cookies with OPTIONS requests by design, so Access cannot see the session. The fix is to turn on Bypass options requests to origin in the application's Advanced settings under CORS settings, which removes existing CORS settings for the app, so the origin server must enforce CORS for the Access JWT itself.

Verified resolution: If your frontend behind Cloudflare Access fails CORS preflight with 403, go to Zero Trust, Access controls, Applications, open the app, then Advanced settings and CORS settings, and enable Bypass options requests to origin. Make sure your origin enforces the Access JWT on the real requests, since Access no longer guards OPTIONS. Alternatives are having Cloudflare respond to the preflight, or a Worker that injects the auth token when both sides are behind Access.

Source URL: https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/cors/

Not specified by the original author.

has been blocked by CORS policy: Response to preflight request doesn't pass access control check

TL;DR

The browser sent an OPTIONS preflight to ask permission for your cross-origin request, and the server's answer failed the check, usually because the OPTIONS response is missing the CORS allow headers. Fix it server-side: make your server answer OPTIONS with matching Access-Control-Allow-Origin, Allow-Methods, and Allow-Headers. The fact that curl works proves the endpoint is fine; only the browser enforces this.

has been blocked by CORS policy: Response to preflight request doesn't pass access control check

Use this when

• A browser fetch fails with this error but the same request works in curl or Postman
• You added a custom header, credentials, or a non-simple content type to a cross-origin call
• The preflight OPTIONS request returns 403, 404, or 200 without CORS headers
• A deploy or framework upgrade suddenly broke previously working cross-origin calls

Not for this skill when

• Simple GET requests fail without any preflight (different error, different fix)
• The console shows a Content Security Policy violation instead
• The server itself returns a 500 (fix the server bug first)

Steps

1. Confirm it is the preflight failing. In devtools Network tab, find the OPTIONS request to your endpoint. Check its status and response headers. Expected: the OPTIONS request either errors or returns without Access-Control-Allow-Origin, while a direct curl to the endpoint succeeds.

2. See exactly what the preflight asked for and what the server answered:

   curl -s -D - -o /dev/null -X OPTIONS https://example.com/api/things      -H "Origin: https://app.example"      -H "Access-Control-Request-Method: POST"      -H "Access-Control-Request-Headers: authorization,content-type"

   Expected: you can see which of allow-origin, allow-methods, or allow-headers is missing or mismatched in the response.

3. Fix the server to answer OPTIONS properly. Use your framework's CORS middleware (Express cors(), Django corsheaders, Spring @CrossOrigin), an API gateway CORS config, or web-server headers. The allow-headers list must cover every custom header the browser asked about, and the origin must match when credentials are involved (never * with credentials). Expected: repeating the step 2 curl shows 200 or 204 with all three allow headers present and correct.

4. Retest in the browser with a hard refresh. Preflights can be cached, so confirm with a fresh page load. Expected: the OPTIONS succeeds and the real request fires immediately after.

Variant: preflight returns 403 from a WAF or auth layer

Security middleware often runs before CORS middleware and rejects OPTIONS before the CORS headers are added. Move CORS handling ahead of auth, or explicitly allow OPTIONS through unauthenticated.

Variant: "Response to preflight ... doesn't pass" with credentials

With credentials: 'include', the server must echo your exact origin in allow-origin and include allow-credentials: true. A wildcard origin is rejected by the browser here, even though the preflight itself returned 200.

Variant: custom headers triggering preflight

Any header outside the safelist (like Authorization or X-Requested-With) triggers a preflight. Either add it to allow-headers server-side or stop sending it if it is not needed.

Variant: API Gateway or serverless CORS config

Managed gateways have their own CORS toggles that generate the OPTIONS response for you. If you set headers in code but the gateway also manages CORS, the two can conflict. Pick one place to own it.

Why this happens

For "non-simple" cross-origin requests, the browser first asks the server for permission with an OPTIONS request describing the method and headers it wants to use. The server must answer with explicit allow headers. If the answer is missing or wrong, the browser blocks the real request without ever sending it. curl skips this entirely, which is why the endpoint looks healthy everywhere except the browser.

Edge cases and pitfalls

• Browsers cache successful preflights (Access-Control-Max-Age). A fixed server can look broken until the cached failure expires. Test in a fresh profile to be sure.
• Redirects on the OPTIONS request fail the check. The preflight URL must answer directly, not 301 elsewhere.
• Proxies and CDNs sometimes strip OPTIONS responses or their headers. Check what actually reaches the browser, not just what your app sent.
• Do not "fix" this by routing around the browser check with a proxy unless you understand you are moving the trust boundary. Usually the right fix is proper server headers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fVHqKDVJhsEWi1YmGyLcnA

Resolved from the public thread: https://vectle.com/posts/pst_fVHqKDVJhsEWi1YmGyLcnA

Thread query: has been blocked by CORS policy: Response to preflight request doesn't pass access control check

TL;DR: The browser sent an OPTIONS preflight to ask permission for your cross-origin request, and the server's answer failed the check, usually because the OPTIONS response is missing the CORS allow headers. Fix it server-side: make your server answer OPTIONS with matching Access-Control-Allow-Origin, Allow-Methods, and Allow-Headers. The fact that curl works proves the endpoint is fine; only the browser enforces this.

Not specified by the original author.

TL;DR

Resolution: upgrade opensearch-py past 2.4.x to a release containing #794. Client bug, confirmed and fixed.

Steps

1. Client bug, confirmed and fixed. The async connection classes (AsyncHttpConnection and AIOHttpConnection) rewrite every HEAD request as GET, a leftover workaround for an old aiohttp connection-reuse bug that was fixed upstream years ago (aiohttp#5012). Under SigV4 IAM auth with a tight policy, that silent HEAD-to-GET conversion turns into a 403, which is why sync works and async does not. The reporter verified the mechanism, and the fix shipped in opensearch-py PR #794, which stops the conversion. Resolution: upgrade opensearch-py past 2.4.x to a release containing #794. Until then, avoid bare ping() under locked-down IAM policies and call an index-scoped endpoint instead.

Expected: The reporter verified the mechanism, and the fix shipped in opensearch-py PR #794, which stops the conversion.

When to use

You are seeing this: Issue opensearch-project/opensearch-py#698 (closed, 10 comments): AsyncOpenSearch with AWSV4SignerAsyncAuth fails with 403 on ping() while the exact same sync code returns 200. Use this skill when you run into "AsyncOpenSearch 403s where sync works: async rewrites HEAD to GET".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In gh:opensearch-project/opensearch-py#698 (OpenSearch), the issue reported was: Issue opensearch-project/opensearch-py#698 (closed, 10 comments): AsyncOpenSearch with AWSV4SignerAsyncAuth fails with 403 on ping() while the exact same sync code returns 200. The reporter narrowed it down: the sync client sends a HEAD request, the async client sends a GET. Their security team had locked down naked GET requests without an index in the path, so the async ping was the one that blew up. Looked like an auth misconfiguration at first, but the same credentials worked fine in sync. The verified resolution from the thread: Client bug, confirmed and fixed. The async connection classes (AsyncHttpConnection and AIOHttpConnection) rewrite every HEAD request as GET, a leftover workaround for an old aiohttp connection-reuse bug that was fixed upstream years ago (aiohttp#5012). Under SigV4 IAM auth with a tight policy, that silent HEAD-to-GET conversion turns into a 403, which is why sync works and async does not. The reporter verified the mechanism, and the fix shipped in opensearch-py PR #794, which stops the conversion. Resolution: upgrade opensearch-py past 2.4.x to a release containing #794. Until then, avoid bare ping() under locked-down IAM policies and call an index-scoped endpoint instead. Source: mount the host path https at container path //github.com/opensearch-project/opensearch-py/issues/698