Skip to main content
Cross-origin errors in the Developer Portal arise from two independent layers: the Portal application itself and the Tyk Gateway APIs that the API Playground calls directly. Identify which layer is failing before applying a fix.
SymptomRequests from your application to the Portal Admin API or Live Portal routes fail. The browser console shows:
Access to fetch at 'https://portal.example.com/...' from origin 'https://app.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Preflight OPTIONS requests to the Portal return 404 Not Found or 405 Method Not Allowed.CausePORTAL_CORS_ENABLE is false (the default). The Portal’s CORS middleware is disabled, so no Access-Control-Allow-Origin header is added to any response and OPTIONS preflight requests fall through to the router with no matching handler.FixEnable Portal CORS and set your allowed origins. See Configure Portal Application CORS.
SymptomTest requests in the API Playground fail. The browser console shows one of:
  • 401 Unauthorized on the OPTIONS preflight request
  • Access to fetch at 'https://api.example.com/...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
CauseThe API definition in Tyk Gateway has CORS misconfigured:
  • CORS disabled entirely: The Gateway routes the OPTIONS preflight through the authentication middleware. Because preflight requests carry no Authorization header, the Gateway rejects them with 401 Unauthorized.
  • CORS enabled but Portal origin not in the allowed list: The Gateway intercepts the preflight and returns 200 OK, but omits the Access-Control-Allow-Origin header because the Portal’s origin does not match allowed_origins. The browser treats this as a CORS failure.
FixConfigure CORS on the API definition and add your Portal URL to the allowed origins. See Configure Gateway CORS for APIs.
SymptomAPI Playground requests fail on Gateway versions v5.8.6 through v5.8.13, even when CORS is correctly configured and the Portal origin is in allowed_origins. The browser console shows:
TypeError: Failed to fetch
The OPTIONS preflight returns 403 Forbidden with one of the following response bodies:
{"error": "Requested endpoint is forbidden"}

{"error": "Access to this API has been disallowed"}
CauseA middleware ordering regression in Gateway versions v5.8.6–v5.8.13 caused the allow-list middleware (VersionCheck) to run before the CORS middleware. The allow-list evaluates the OPTIONS method against endpoint rules and returns 403 Forbidden before the CORS middleware can intercept and handle the preflight.FixUpgrade Tyk Gateway to v5.8.14 or later, where the middleware ordering is corrected.
SymptomCredentialed cross-origin requests to the Portal fail. The browser console shows:
The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
CausePORTAL_CORS_ALLOW_CREDENTIALS=true is set alongside an unset or wildcard PORTAL_CORS_ALLOWED_ORIGINS. When PORTAL_CORS_ALLOWED_ORIGINS is unset or set to *, the Portal responds with Access-Control-Allow-Origin: *. The CORS specification forbids combining a wildcard origin with Access-Control-Allow-Credentials: true, so the browser rejects the response.FixSet PORTAL_CORS_ALLOWED_ORIGINS to specific origins or to http://*,https://* to allow all. Both prevent the wildcard * response that browsers block when credentials are in use:
# Restrict to specific origins
PORTAL_CORS_ALLOWED_ORIGINS=https://admin.example.com,https://app.example.com
PORTAL_CORS_ALLOW_CREDENTIALS=true

# Allow all origins
PORTAL_CORS_ALLOWED_ORIGINS=http://*,https://*
PORTAL_CORS_ALLOW_CREDENTIALS=true
See Configure Portal Application CORS.