CORS errors

Identifying a CORS issue

To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:

1. Navigate to the website or web app in question and open the Developer Tools.
2. Now try to reproduce the failing transaction and check the console if you are seeing a CORS violation error message. It will probably look like this:

The text of the error message will be something similar to the following:

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).

Client-side considerations

Most CORS errors can only be resolved on the server, because the server controls whether cross-origin access is allowed. However, there are some things you can do on the client side:

Avoid triggering a preflight

Browsers send a preflight request before the actual request when certain conditions are met (custom headers, methods other than GET/HEAD/POST, or non-simple content types). If the server does not handle preflight requests, you can restructure your request to qualify as a simple request:

• Use only GET, HEAD, or POST methods.
• Set only CORS-safelisted request headers (such as Accept, Content-Language, or Content-Type).
• Use only application/x-www-form-urlencoded, multipart/form-data, or text/plain for Content-Type.

Simple requests bypass the preflight step entirely, which avoids a class of CORS errors related to preflight handling.

Use no-cors mode for opaque responses

If you do not need to read the response body or headers - for example, when sending analytics beacons or loading resources into a cache via a service worker - you can set the mode to "no-cors" in a fetch() call:

fetch("https://api.example.com/log", {
  method: "POST",
  mode: "no-cors",
  body: data,
});

The response will be opaque: its status is 0, its headers are empty, and its body is not readable by JavaScript. This is by design - no-cors disables the CORS check, but in exchange you lose all access to the response content.

Use a proxy server

If you do not control the remote server and it does not set CORS headers, you can route requests through a server you do control. Your server fetches the resource on your behalf and returns it with appropriate CORS headers. This approach adds latency and introduces a dependency on your proxy, but it works when other options are unavailable.

CORS error messages

Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong. The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.

• Reason: CORS disabled
• Reason: CORS request did not succeed
• Reason: CORS header 'Origin' cannot be added
• Reason: CORS request external redirect not allowed
• Reason: CORS request not http
• Reason: CORS header 'Access-Control-Allow-Origin' missing
• Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
• Reason: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*'
• Reason: Did not find method in CORS header 'Access-Control-Allow-Methods'
• Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials'
• Reason: CORS preflight channel did not succeed
• Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
• Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
• Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
• Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed

Most CORS errors can only be resolved on the server, because the server controls whether cross-origin access is allowed. However, there are some things you can do on the client side:

Avoid triggering a preflight

Browsers send a preflight request before the actual request when certain conditions are met (custom headers, methods other than GET/HEAD/POST, or non-simple content types). If the server does not handle preflight requests, you can restructure your request to qualify as a simple request:

• Use only GET, HEAD, or POST methods.
• Set only CORS-safelisted request headers (such as Accept, Content-Language, or Content-Type).
• Use only application/x-www-form-urlencoded, multipart/form-data, or text/plain for Content-Type.

Simple requests bypass the preflight step entirely, which avoids a class of CORS errors related to preflight handling.

Use no-cors mode for opaque responses

If you do not need to read the response body or headers — for example, when sending analytics beacons or loading resources into a cache via a service worker — you can set the mode to "no-cors" in a fetch() call:

fetch("https://api.example.com/log", {
  method: "POST",
  mode: "no-cors",
  body: data,
});

The response will be opaque: its status is 0, its headers are empty, and its body is not readable by JavaScript. This is by design — no-cors disables the CORS check, but in exchange you lose all access to the response content.

Use a proxy server

If you do not control the remote server and it does not set CORS headers, you can route requests through a server you do control. Your server fetches the resource on your behalf and returns it with appropriate CORS headers. This approach adds latency and introduces a dependency on your proxy, but it works when other options are unavailable.

See also

• Glossary: CORS
• CORS introduction
• Server-side CORS settings
• CORS enabled image
• CORS settings attributes