What is CORS and Why Does It Exist?

In the previous article, we learned that an Origin consists of three components:

• Scheme (Protocol)
• Host
• Port

Browsers use these three components to determine whether a request is Same-Origin or Cross-Origin.

Whenever a web page attempts to access resources from a different Origin, a security mechanism called CORS (Cross-Origin Resource Sharing) comes into play.

📌 Why Does a CORS Error Occur?

Suppose your web application is running at:

https://app.example.com

Now it tries to fetch data from:

https://api.example.com

Although both URLs belong to example.com, their Hosts are different.

That means they have different Origins.

As a result, the browser treats this as a Cross-Origin request.

If the destination server does not explicitly allow this Origin, the browser prevents JavaScript from accessing the response, resulting in what we commonly call a CORS Error.

💡 Important: CORS is a browser security mechanism, not a server security mechanism.

⚠️ A Common Misconception About CORS

Many developers believe that a CORS error means the request never reached the server.

In most cases, that's simply not true.

Typically:

• ✅ The browser sends the request.
• ✅ The server receives it.
• ✅ The server generates and returns a response.
• ❌ The browser blocks JavaScript from accessing that response.

In other words, the request was successful—the browser simply refuses to expose the response to your application because the CORS policy was not satisfied.

This is why sending the exact same request using tools like Postman or curl usually works without any problems.

Those tools are not browsers, so they do not enforce browser security policies like CORS.

📦 How Does the Server Handle CORS?

To allow JavaScript to access the response, the server must include the appropriate CORS headers.

The most important one is:

Access-Control-Allow-Origin: https://app.example.com

This header tells the browser that JavaScript running on https://app.example.com is allowed to read the response.

✅ Examples

Suppose your Front-end is running at:

https://app.example.com

and the server responds with:

Access-Control-Allow-Origin: https://app.example.com

The browser allows JavaScript to access the response. ✅

Now suppose the Front-end is running at:

https://admin.example.com

but the server still responds with:

Access-Control-Allow-Origin: https://app.example.com

The browser blocks access to the response because the Origin does not match. ❌

Another example:

Front-end:

https://evil.com

Server response:

Access-Control-Allow-Origin: https://app.example.com

Again, the browser blocks the response because evil.com is not an allowed Origin.

If the server instead responds with:

Access-Control-Allow-Origin: *

then every Origin is allowed to access the resource.

However, this should only be used for public resources. APIs that require authentication or expose sensitive data should never rely on a wildcard Origin.

📌 CORS and Cookies

When Cookies or other authentication credentials need to be included in a Cross-Origin request, configuring only Access-Control-Allow-Origin is not enough.

Additional settings are required, including:

• Access-Control-Allow-Credentials
• The credentials option in the Fetch API

We'll cover these in detail in the next article.

📌 Summary

Whenever a request is made to a different Origin, the browser applies the Same-Origin Policy.

If the server explicitly allows the requesting Origin using the appropriate CORS headers, JavaScript is allowed to access the response.

Otherwise, the browser hides the response from JavaScript and reports a CORS error.

This is why fixing CORS issues is usually a Back-end configuration task—not a Front-end one.