Introduction

An API migration can look complete in server logs while browsers still refuse every request. That usually means the API now lives on a different origin, but the CORS policy still reflects the old hostname or path assumptions. Because browser enforcement happens before your app code sees the response, the outage feels inconsistent and confusing. The fix is to treat the new browser origin as a contract and update allowlists, preflight behavior, and credential rules together.

Symptoms

  • Browser requests to the API fail immediately after a domain or subdomain move
  • Server-to-server requests still work while front-end calls fail
  • Developer tools show blocked preflight requests or missing Access-Control-Allow-Origin
  • Only logged-in flows fail because cookies or auth headers are involved
  • The problem started after moving the API behind a gateway, CDN, or new hostname

Common Causes

  • The API still allows only the old front-end origin
  • Preflight OPTIONS requests are blocked, redirected, or unauthenticated
  • Credentialed requests use a wildcard CORS policy that browsers reject
  • A proxy, CDN, or load balancer strips or rewrites the relevant headers
  • The front end now calls a hostname that does not match the intended CORS configuration

Step-by-Step Fix

  1. Reproduce the failing request in the browser and inspect both the preflight and final response headers.
  2. Compare the current front-end origin to the API allowlist so you can see whether the new hostname was ever added.
  3. Verify the API returns the correct Access-Control-Allow-Origin value for the requesting site instead of a stale or overly broad policy.
  4. Check that OPTIONS requests are answered successfully without being redirected to login, HTTP to HTTPS, or another host.
  5. If cookies or authenticated browser sessions are involved, confirm the response headers are compatible with credentialed requests.
  6. Review CDN, gateway, reverse proxy, and application middleware so none of them strip or overwrite the CORS headers you expect.
  7. Align the front-end environment variables and API base URL so the browser is calling the intended production origin.
  8. Re-test the exact failing route and method after the header changes rather than assuming one successful endpoint fixes the whole API.
  9. Keep origin allowlists and deployment configs synchronized so future domain moves do not break browser access again.