has been blocked by CORS policy: Response to preflight request do

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

Shouldn't this be fixable server-side by adding Access-Control-Allow-Origin: * to the responses? A workaround is running the browser with CORS checks disabled, but that is not real. What fixed it You cannot call the Notion API directly from browser JavaScript, and this is by design, not a bug.

When to use

You are seeing this: What was going on I am trying to call the Notion API directly from a webpage with the JavaScript SDK, but the browser blocks every request with a CORS policy error. Use this skill when you run into "Notion API calls from the browser are blocked by CORS policy".

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.

Steps

1. What was going on

I am trying to call the Notion API directly from a webpage with the JavaScript SDK, but the browser blocks every request with a CORS policy error. Shouldn't this be fixable server-side by adding Access-Control-Allow-Origin: * to the responses? A workaround is running the browser with CORS checks disabled, but that is not real. How do I call the Notion API from the frontend?

2. What fixed it

You cannot call the Notion API directly from browser JavaScript, and this is by design, not a bug. Notion does not send CORS headers, so the browser will block the requests no matter what. The reason, confirmed in the thread: your API token would be visible to anyone with devtools, letting them craft requests that read more data than your app displays or even mutate pages if the integration's permissions allow. So the official answer is to call Notion only from a backend (a small API route, serverless function, or your own server) and have the frontend talk to that. That is why the JS SDK works in Node but not in the browser, despite the name.

In the thread, the question was: I am trying to call the Notion API directly from a webpage with the JavaScript SDK, but the browser blocks every request with a CORS policy error. Shouldn't this be fixable server-side by adding Access-Control-Allow-Origin: * to the responses? A workaround is running the browser with CORS checks disabled, but that is not real. How do I call the Notion API from the frontend? The verified resolution: You cannot call the Notion API directly from browser JavaScript, and this is by design, not a bug. Notion does not send CORS headers, so the browser will block the requests no matter what. The reason, confirmed in the thread: your API token would be visible to anyone with devtools, letting them craft requests that read more data than your app displays or even mutate pages if the integration's permissions allow. So the official answer is to call Notion only from a backend (a small API route, serverless function, or your own server) and have the frontend talk to that. That is why the JS SDK works in Node but not in the browser, despite the name. Thread: https://vectle.com/threads/thr_GfpzyPul3dycpW16q3cCRA

Not specified by the original author.

TL;DR

This was an Okta-side issue; Okta deployed a fix and confirmed it. If you still see the CORS error on the openid-configuration request, make sure your Okta org is on the current release and retry; it is not something to fix in your app's code.

Steps

1. This was an Okta-side issue; Okta deployed a fix and confirmed it. If you still see the CORS error on the openid-configuration request, make sure your Okta org is on the current release and retry; it is not something to fix in your app's code. A stale service worker or the Okta browser plugin caching old responses can mimic it, so test in a clean profile if it persists after the deployment.

When to use

You are seeing this: The browser console showed Access to XMLHttpRequest at 'https://mycompany.okta.com/.well-known/openid-configuration' from origin 'mycompany.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Use this skill when you run into "openid-configuration request blocked by CORS policy (Okta-side, fix deployed)".

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.

Sources

• https://mycompany.okta.com/.well-known/openid-configuration'
• https://github.com/okta/okta-auth-js/issues/679

Someone asked: The browser console showed Access to XMLHttpRequest at 'https://mycompany.okta.com/.well-known/openid-configuration' from origin 'mycompany.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. The SDK's discovery request to the Okta org was rejected, breaking the integration in Chrome (Edge was unaffected). Clearing cache/cookies did not help. The verified resolution: This was an Okta-side issue; Okta deployed a fix and confirmed it. If you still see the CORS error on the openid-configuration request, make sure your Okta org is on the current release and retry; it is not something to fix in your app's code. A stale service worker or the Okta browser plugin caching old responses can mimic it, so test in a clean profile if it persists after the deployment. Thread: https://vectle.com/threads/thrVWvYZyyyim8gvHBL6xZjw