Confirm the browser-only failure
After a hostname change, compare the browser's new Origin with the API response and update only the intended allowed origin.
A hostname change can alter the browser Origin even while the API itself remains reachable. CORS is a browser rule about whether script from one origin may read a response from another. An origin includes scheme, hostname and port; changing any of them can make a previously same-origin request cross-origin. Record the intended front-end URL, API request URL and the failing action. A direct browser visit to an API endpoint does not prove that a scripted cross-origin request is permitted.
Use this guide only for an application the customer owns and an API they are authorised to configure. If the request itself returns a 500/503 or unexpectedly redirects, fix that underlying response first.
Capture the safe request and response facts
In the browser Network and Console views, identify the failing request and any preceding OPTIONS preflight. Record the request Origin, requested URL, HTTP status and relevant Access-Control-Allow-Origin, methods, headers and credentials response headers, without copying tokens, cookies or private API data. A redirect during preflight can produce its own browser error. Compare the exact origin against the API’s intended allowlist; an old hostname or HTTP-to-HTTPS change is easy to overlook.
Do not assume a missing CORS header is always an API policy error. A proxy, authentication redirect or error page can return a different response path. Give platform support safe header and time evidence only if an in-scope proxy is demonstrably changing the response.
Change the application policy narrowly
The API owner should update the endpoint URL or allowlist for the exact approved front-end origin, following the API framework’s documented configuration. If the browser sends credentials, do not use a wildcard Access-Control-Allow-Origin: *; MDN documents that this combination is rejected. Keep the intended allowed methods and headers as narrow as the application needs. Do not remove CORS checks, broadly reflect arbitrary Origin values or disable another security control to make one request pass.
Test the real action and a denied origin
Retry the application action in a fresh browser session, with credentials only if that flow requires them. Confirm the preflight and actual request now complete and the feature shows the expected result. Where the owner has a safe test harness, verify an unrelated origin is still denied. If the action remains broken, compare its new status and response with the previous evidence and roll back the policy change if it broadened access without solving the fault.
For example, test the affected browser action from the new front-end origin and read its preflight and final responses. A direct API health check cannot prove the browser's credentialed CORS request succeeds.
Frequently asked questions
Why does an API health URL work while the app fails? A direct visit does not test the browser’s cross-origin read permission or its preflight.
Can hosting add a wildcard header for us? That may be unsafe and can fail for credentialed requests. The API owner should define the permitted origin; platform help depends on the contracted proxy scope.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.