Modern web applications often communicate with APIs hosted on different domains.
For example, a frontend application may run on one domain while its backend API runs on another.
At first, this may seem simple. The frontend sends a request, and the server sends back a response.
However, web browsers have important security rules that control which websites can access resources from other origins.
This is where CORS becomes important.
CORS stands for Cross-Origin Resource Sharing. It is a browser security mechanism that allows servers to specify which origins are permitted to access their resources.
For example, your frontend may run on:
https://myfrontend.com
while your API runs on:
https://api.mybackend.com
Because these are different origins, the browser may block the frontend from accessing the API response unless the server allows it through CORS.
In this article, we’ll explain what CORS is, how CORS works, why browsers enforce it, what preflight requests are, and how developers can configure CORS safely.
What Is CORS?
CORS stands for Cross-Origin Resource Sharing.
It is a mechanism that allows a server to tell a browser which websites are allowed to access its resources.
CORS is mainly enforced by web browsers.
For example, imagine this situation:
Frontend Application
https://website-a.com
↓
↓ Request
↓
API Server
https://website-b.com
The frontend and API are on different origins.
Therefore, the browser checks whether the API server allows website-a.com to access its resources.
If the server sends the correct CORS headers, the browser allows JavaScript to access the response.
Otherwise, the browser blocks access to the response.
What Is an Origin?
Before understanding CORS, it is important to understand the meaning of origin.
An origin is based on three parts:
- Protocol
- Domain
- Port
For example:
https://example.com:443
The origin includes:
Protocol → https
Domain → example.com
Port → 443
Changing any of these can create a different origin.
For example:
http://example.com
and:
https://example.com
are different origins because the protocol is different.
Similarly:
https://example.com
and:
https://api.example.com
are also different origins because the host is different.
Why Does CORS Exist?
Web browsers use a security rule called the Same-Origin Policy.
This policy helps prevent one website from freely reading data from another website.
Imagine if any website could make a request to your bank’s website and read your account information.
That would create a serious security problem.
For example, without browser protections, a malicious website could potentially attempt something like:
Malicious Website
↓
Request User Data
↓
Bank Website
The Same-Origin Policy helps prevent JavaScript running on one origin from freely reading sensitive responses from another origin.
CORS provides a controlled way for servers to relax this restriction.
How Does CORS Work?
The basic CORS process looks like this:
Frontend → Cross-Origin Request → Server → CORS Headers → Browser Checks Headers → Allow or Block JavaScript Access
Let’s understand this step by step.
Step 1: A Website Makes a Request
Suppose your frontend runs on:
https://frontend.com
Your JavaScript sends a request to:
https://api.example.com
For example:
fetch("https://api.example.com/users");
The browser recognizes that the request is cross-origin.
Therefore, it applies CORS rules.
Step 2: The Browser Sends the Request
For many simple requests, the browser sends the request directly.
Conceptually:
Browser
↓
Request
↓
API Server
The browser also includes information about where the request originated.
For example:
Origin: https://frontend.com
Step 3: The Server Sends CORS Headers
The API server can respond with a header such as:
Access-Control-Allow-Origin: https://frontend.com
This tells the browser:
Requests from
https://frontend.comare allowed to access this response.
The browser then checks the response.
Step 4: The Browser Decides Whether JavaScript Can Access the Response
If the server allows the frontend origin:
https://frontend.com
the browser allows JavaScript to access the response.
Conceptually:
Frontend
↓
Request API
↓
API Response + CORS Permission
↓
Browser Checks Permission
↓
JavaScript Can Read Response
However, if the server does not allow the origin, the browser blocks JavaScript from reading the response.
Important: CORS Is Mainly a Browser Security Mechanism
One of the most important things to understand is that CORS is mainly enforced by browsers.
The API server can still receive a request.
However, the browser may prevent JavaScript from accessing the response.
For example:
Frontend JavaScript
↓
Browser Sends Request
↓
API Server Receives Request
↓
API Sends Response
↓
Browser Checks CORS
↓
JavaScript Access Allowed or Blocked
This is why CORS errors can sometimes confuse developers.
The server may successfully process the request, but the browser can still block frontend JavaScript from reading the response.
A Simple CORS Example
Suppose your frontend is:
http://localhost:3000
Your backend is:
http://localhost:5000
Even though both are running on your computer, they are different origins because the ports are different.
The browser treats them as:
Origin 1
http://localhost:3000
Origin 2
http://localhost:5000
Therefore, the backend may need to allow requests from the frontend.
For example:
Access-Control-Allow-Origin: http://localhost:3000
After that, the browser can allow the frontend JavaScript to access the response.
What Is Access-Control-Allow-Origin?
The most common CORS response header is:
Access-Control-Allow-Origin
For example:
Access-Control-Allow-Origin: https://frontend.com
This allows that specific origin to access the response.
Sometimes a server may use:
Access-Control-Allow-Origin: *
The * means that any origin can access the response, subject to the limitations of CORS and the request type.
However, allowing every origin is not appropriate for every API.
For sensitive APIs, it is generally better to explicitly allow trusted origins.
What Is a CORS Preflight Request?
Some cross-origin requests require a preflight request.
Before sending the actual request, the browser sends an OPTIONS request to check whether the server allows the intended cross-origin request.
The process looks like this:
Browser
↓
OPTIONS Request
↓
Server
↓
Permission Response
↓
Browser
↓
Actual Request
The preflight request asks the server whether the browser can safely make the intended request.
Why Does the Browser Send a Preflight Request?
Some requests have a greater potential impact than simple requests.
For example, a request may:
- Use methods such as
PUT,PATCH, orDELETE - Include certain non-safelisted request headers
- Use a non-safelisted
Content-Type
In these cases, the browser may send a preflight request before sending the actual request.
This allows the server to specify what is permitted.
Example of a Preflight Request
Suppose your frontend wants to send:
DELETE /users/101
Before sending the request, the browser may send:
OPTIONS /users/101
The request can include headers such as:
Origin: https://frontend.com
Access-Control-Request-Method: DELETE
The server can then respond with:
Access-Control-Allow-Origin: https://frontend.com
Access-Control-Allow-Methods: DELETE
If the browser determines that the request is allowed, it can proceed with the actual request.
Important CORS Headers
Several headers are commonly used when configuring CORS.
1. Access-Control-Allow-Origin
This specifies which origin can access the resource.
Example:
Access-Control-Allow-Origin: https://frontend.com
2. Access-Control-Allow-Methods
This specifies which HTTP methods are allowed.
Example:
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
3. Access-Control-Allow-Headers
This specifies which request headers the browser is allowed to send.
Example:
Access-Control-Allow-Headers: Content-Type, Authorization
This can be important when the frontend sends headers such as:
Authorization
or custom application headers.
4. Access-Control-Allow-Credentials
This is used when cross-origin requests need to include credentials such as cookies.
For example:
Access-Control-Allow-Credentials: true
However, credentialed CORS requests require careful configuration.
In particular, a response that allows credentials cannot use Access-Control-Allow-Origin: *. The server must return an appropriate specific origin.
Simple Request vs Preflight Request
CORS requests are often explained in two categories.
Simple Requests
Some requests can be sent directly by the browser without a CORS preflight.
The browser still checks the server’s CORS response headers before exposing the response to JavaScript.
Preflighted Requests
Other requests require the browser to first send an OPTIONS request.
The server must indicate that the requested cross-origin operation is permitted.
Then, if the preflight succeeds, the browser sends the actual request.
CORS Example With JavaScript
Suppose a frontend application makes this request:
fetch("https://api.example.com/products", {
method: "GET"
});
If the server responds with:
Access-Control-Allow-Origin: https://frontend.com
and the page was loaded from that allowed origin, the browser can expose the response to the JavaScript code.
CORS Example With an Authorization Header
Suppose the frontend sends:
fetch("https://api.example.com/profile", {
headers: {
Authorization: "Bearer token"
}
});
Because this request includes a non-safelisted header, the browser may perform a preflight request.
The server needs to allow the appropriate origin and header.
For example:
Access-Control-Allow-Origin: https://frontend.com
Access-Control-Allow-Headers: Authorization
If the CORS checks succeed, the browser can proceed with the request flow.
How to Enable CORS in Node.js
In a Node.js application using Express, developers often use the cors middleware.
Conceptually:
app.use(cors());
This can enable a broad CORS configuration.
However, production applications should usually configure allowed origins carefully.
For example:
app.use(
cors({
origin: "https://frontend.com"
})
);
This allows requests from the specified frontend origin.
CORS With Cookies
CORS becomes more complex when cookies or other credentials are involved.
Suppose the frontend runs on:
https://frontend.com
and the backend runs on:
https://api.example.com
If the browser needs to include credentials, the frontend may need to explicitly configure the request.
For example:
fetch("https://api.example.com/profile", {
credentials: "include"
});
The server must also allow credentials and return an appropriate specific origin.
Conceptually:
Access-Control-Allow-Origin: https://frontend.com
Access-Control-Allow-Credentials: true
Using a wildcard origin is not compatible with credentialed CORS responses.
Common CORS Error
Developers often see an error similar to:
Blocked by CORS policy
This usually means the browser did not receive a response with CORS permissions that matched the cross-origin request.
Common causes include:
- The server does not allow the frontend origin.
- A required HTTP method is not allowed.
- A required request header is not allowed.
- The preflight request fails.
- Credentials are configured incorrectly.
The solution is usually to configure the API server correctly.
Can You Fix CORS From the Frontend?
Usually, a CORS problem cannot be properly fixed only from frontend JavaScript.
The browser is enforcing the server’s permissions.
Therefore, the server must return the correct CORS headers.
Trying to disable browser security or use unsafe workarounds is not a proper production solution.
Instead, developers should configure CORS on the backend or use an appropriate server-side architecture.
CORS vs Same-Origin Policy
CORS and the Same-Origin Policy are closely related.
| Same-Origin Policy | CORS |
|---|---|
| Browser security restriction | Controlled permission mechanism |
| Restricts cross-origin access | Allows servers to permit specific cross-origin access |
| Protects users and websites | Provides controlled exceptions |
In simple terms:
Same-Origin Policy restricts access.
CORS allows servers to define when cross-origin access is permitted.
CORS Does Not Replace Authentication
CORS is not an authentication or authorization system.
This is a very important point.
CORS controls whether a browser allows JavaScript from one origin to read a response from another origin.
It does not determine whether a user is authorized to access sensitive data.
A secure API should still use proper:
- Authentication
- Authorization
- Input validation
- Rate limiting
- Security controls
Therefore, CORS should not be treated as a security boundary that protects an API from all unwanted requests.
CORS Does Not Stop All Requests
Another common misunderstanding is that CORS completely prevents requests from reaching a server.
In many situations, the request can still reach the server.
CORS mainly controls whether browser JavaScript is allowed to access the response.
For example, tools such as server-side applications, command-line clients, and other non-browser systems are not governed by browser CORS enforcement in the same way.
Therefore, APIs should always implement real server-side security.
When Do You Need CORS?
You usually need to consider CORS when:
- Your frontend and backend use different origins.
- A web application calls a third-party API from browser JavaScript.
- Your frontend runs on a different domain or port from your API.
For example:
Frontend
https://app.example.com
API
https://api.example.com
These are different origins.
Therefore, browser requests between them may require appropriate CORS configuration.
When Do You Not Need CORS?
You generally do not need cross-origin CORS permissions when the browser request and resource are from the same origin.
For example:
https://example.com
↓
Request
↓
https://example.com/api/users
The protocol, host, and port match.
Therefore, the request is same-origin.
Best Practices for Configuring CORS
Developers should configure CORS carefully.
1. Allow Only Trusted Origins
Instead of allowing every origin, explicitly define trusted frontend applications when possible.
For example:
https://app.example.com
2. Limit Allowed Methods
Allow only the HTTP methods your API actually needs.
3. Limit Allowed Headers
Avoid unnecessarily allowing arbitrary headers.
4. Configure Credentials Carefully
If your application uses cross-origin cookies, configure credentials intentionally.
Also, use a specific allowed origin rather than *.
5. Handle Preflight Requests Correctly
Make sure the server responds correctly to required OPTIONS requests.
6. Do Not Use CORS as Authentication
CORS does not replace authentication or authorization.
Your API must still verify every sensitive request on the server.
A Complete CORS Request Flow
Here is a simplified example:
Step 1: User Opens the Frontend
https://frontend.com
Step 2: JavaScript Requests the API
https://api.example.com/users
Step 3: Browser Detects a Cross-Origin Request
The browser checks whether additional CORS rules apply.
Step 4: Browser May Send a Preflight Request
For requests that require preflight:
Browser
↓
OPTIONS Request
↓
API
Step 5: Server Sends CORS Permissions
For example:
Access-Control-Allow-Origin: https://frontend.com
Step 6: Browser Sends or Completes the Actual Request
The server processes the request.
Step 7: Browser Checks the Response
If the CORS permissions match:
JavaScript Can Access Response
Otherwise:
Browser Blocks JavaScript Access
The complete process can be summarized as:
Frontend → Cross-Origin Request → Browser Checks CORS → Server Sends Permissions → Browser Allows or Blocks Response Access
Final Thoughts: How Does CORS Work?
CORS is a browser mechanism that controls whether a web application can access resources from a different origin.
When a browser makes a cross-origin request, it checks whether the server explicitly allows that origin.
For some requests, the browser first sends a preflight request to check the server’s permissions.
The server then responds with CORS headers.
The browser uses those headers to decide whether JavaScript can access the response.
The key idea is:
Browser → Cross-Origin Request → Server → CORS Headers → Browser Checks Permission → Allow or Block JavaScript Access
Conclusion
CORS is an important part of modern web development.
It allows frontend applications to communicate with APIs on different origins while maintaining browser security controls.
Understanding origins, the Same-Origin Policy, CORS headers, and preflight requests can help developers diagnose common CORS errors.
The most important thing to remember is that CORS is mainly a browser-enforced mechanism.
It controls cross-origin access to responses in the browser, but it does not replace proper backend security.
By configuring allowed origins, methods, headers, and credentials carefully, developers can enable cross-origin communication while keeping their applications secure.
