Skip to content
IntelliAuth

CORS errors from the browser

Problem

Section titled “Problem”

Browser console shows:

Access to fetch at 'https://banking-cymmetri.intelliauth.local/api/v1/me/profile'
from origin 'https://app.cymmetri.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

The network tab shows the request itself succeeding (200 status) but the browser refuses to expose the response to your code.

Cause

Section titled “Cause”

Your application's allowed_origins list doesn't include the origin your browser is calling from. The platform refuses the CORS preflight when the Origin header doesn't match.

The OAuth endpoints (/oauth2/authorize, /oauth2/token) are normally exempt — they're hit via redirect or server-to-server. The error usually shows up on the API surfaces called by browser fetch (/api/v1/me/*, /api/v1/auth/*).

Resolution

Section titled “Resolution”

In the tenant admin console, find the application your code is using:

  1. Applications → your application → Settings.
  2. Find the Allowed origins field.
  3. Add your origin. Exact match, including scheme and port. Example: https://app.cymmetri.com (no trailing slash, no path).
  4. Save.

For local development, add http://localhost:5173 (Vite default), http://localhost:3000 (Next.js / Express default), or whatever your dev server runs on.

The CORS check is on the Origin header which the browser sends automatically. You cannot work around it from JavaScript.

Section titled “Related quirks”
  • Wildcards — the platform refuses * in allowed_origins. Specific origins only.
  • The browser caches the preflight. After adding the origin, you may still see CORS errors for up to an hour as the cached OPTIONS response is reused. Hard-reload (Cmd-Shift-R) or wait it out.
  • Credentials mode. The SDK uses credentials: 'include' for the cookie-bearing calls. If you're hand-rolling the fetch, make sure you do too — otherwise the browser refuses to send the session cookie even when CORS allows the origin.

When CORS isn't the actual problem

Section titled “When CORS isn't the actual problem”

Sometimes the "CORS error" is misleading — the underlying request returned 401 / 500 and the browser's CORS layer reports it as a CORS failure because the failed response lacks the CORS headers (the platform only sets them on success). Check the actual response status in the network tab; if it's not 200/2xx, fix the underlying error first.