What is CORS and why does the browser block a request to your API?
Published on 2026-10-20 by frfrand
Qué es CORS, cómo funciona el preflight OPTIONS, diferencia con autenticación y cómo configurarlo sin permitir cualquier origen.
CORS is a browser mechanism that controls when code from a page can read responses from another origin. Its acronym stands for Cross-Origin Resource Sharing. If a frontend on app.ejemplo.com attempts to query an API on api.ejemplo.com, CORS may come into play because the origins are different.
It is not an Internet failure nor an authentication system. It is a policy related to the browser and cross-site security.
What does origin mean?
On a web page, origin is defined by scheme, hostname, and port. https://ejemplo.com and http://ejemplo.com do not have the same origin. Nor do https://ejemplo.com and https://api.ejemplo.com.
This distinction exists so that any page cannot freely read data from other sites where a person has open sessions.
A everyday example
Imagine you are inside your bank in one tab and open an unknown website in another. It would be dangerous if that second website could automatically query your account details and read the response just because your browser has a bank session.
The browser applies the same-origin policy and allows certain controlled exceptions through CORS. The server decides which origins it authorizes to read certain responses.
What does the server do?
A response can include Access-Control-Allow-Origin to indicate which origin is allowed. For example, an API intended for a single frontend could explicitly authorize https://app.ejemplo.com.
It is not always appropriate to use *. If the API sends private data or relies on credentials, the configuration must be much more specific. In addition, there are special rules for credentialed requests.
CORS does not replace backend access controls. A client that is not a browser can call an API directly even if it does not send the Origin header.
What is a preflight OPTIONS?
In certain requests, the browser first checks whether the operation is allowed, usually via an HTTP OPTIONS request. This prior check is called a preflight.
It can happen, for example, when the frontend needs to send certain custom headers or methods. The server must respond with compatible information about allowed methods and headers.
A common mistake is configuring a POST route correctly but forgetting that the server or proxy must handle the preflight. From the browser it looks like the API is down, even though it responds perfectly from another tool.
How to investigate a CORS error?
First open the browser developer tools and look at the failed request, its origin, its headers and the response. Check if there was a prior OPTIONS call.
Then verify the backend configuration and any intermediate proxy. Do not start by adding duplicate headers in Nginx and in the application without knowing which of the two layers will manage them.
Another mistake is installing an extension that temporarily disables browser restrictions and assuming you have already fixed the application. That only hides the symptom on your machine.
CORS does not protect your API from abusive use
Although an unauthorized website cannot read certain responses via JavaScript from the browser, your API still needs authentication, authorization, validation, traffic limits, and appropriate protection against web attacks.
CORS does not by itself prevent someone from calling a public endpoint from a server-side script.
What about ArduMaker?
If you deploy a frontend and a backend under different domains on ArduMaker, you need to define which origins can consume your API from a browser. Configuring it correctly in the application is usually more secure than indiscriminately allowing any origin.
In one sentence: CORS controls certain cross-origin reads performed by browsers. The error is not fixed by "turning off security," but by authorizing the necessary origins and verifying how the server responds.
Sources: CORS on MDN · Same-origin policy.