CORS for Beginners: Why the Browser Sometimes Blocks Your Request

If you are learning frontend development, APIs, or JavaScript, there is a decent chance you have seen an error that looks something like this:

• "Blocked by CORS policy"
• "No 'Access-Control-Allow-Origin' header"
• "Cross-origin request blocked"

And yes, the first time you see it, it feels like the browser woke up angry.

The good news is that CORS is not random.
It is a browser security rule with a specific purpose.

In this post, we will break down what CORS is, why it exists, and how to think about it without drowning in jargon.

Start with the short version

CORS is a browser rule that controls when a webpage is allowed to make requests to a different origin.

That raises another beginner question immediately:

What is an origin?

An origin is basically a combination of:

• protocol
• domain
• port

So these are different origins:

• https://myapp.com
• http://myapp.com
• https://api.myapp.com
• https://myapp.com:3000

Even if they look related, the browser treats them as different origins if one of those parts changes.

A simple example

Imagine your frontend is running here:

https://myfrontend.com

And it tries to fetch data from:

https://api.other-site.com/data

That is a cross-origin request.

The browser notices that the page origin and the API origin are different.
Then it checks whether the server allows that request.

If the server does not allow it, the browser blocks access to the response.

Why does CORS exist?

Because browsers are trying to protect users.

Without rules like this, a malicious website could load in your browser and quietly try to make requests to other sites using your session, cookies, or login state.

CORS is part of the defense.
It helps servers say:

• "Yes, this website can access my responses"
• "No, that other website cannot"

So CORS is not there to annoy developers.
It is there because browsers are suspicious for a reason.

Same-origin policy comes first

Before CORS makes sense, you need one idea:

Browsers have a same-origin policy.

That policy says a page usually cannot freely read responses from a different origin.

CORS is the mechanism that allows a server to relax that rule when it wants to.

So a helpful mental model is:

• same-origin policy = the default restriction
• CORS = the server-controlled exception

How does the server allow it?

The server sends special HTTP headers.

One of the most common is:

Access-Control-Allow-Origin: https://myfrontend.com

That tells the browser:

"It is okay for this specific origin to read the response."

Sometimes you may also see:

Access-Control-Allow-Origin: *

That means "any origin is allowed".

That can be useful for truly public resources, but it is not always appropriate, especially when credentials are involved.

Important beginner point: the browser enforces CORS

This part confuses a lot of people.

CORS is mainly a browser behavior.
The server sends headers, but the browser decides whether frontend JavaScript is allowed to read the response.

That means:

• a request might fail in the browser
• but the same request might work fine in Postman, curl, or server-side code

Why?
Because Postman and curl are not browsers.
They do not apply browser CORS rules in the same way.

So if something works in Postman but fails in your frontend, CORS is a very common suspect.

What is a preflight request?

Some cross-origin requests are considered simple.
Others need an extra permission check first.

That extra check is called a preflight request.

The browser sends an OPTIONS request before the real request and asks something like:

• Can I use POST?
• Can I send this custom header?
• Can I include certain content types?

If the server responds with the right CORS headers, the browser continues with the real request.
If not, the browser blocks it.

A simplified flow looks like this:

1. Browser wants to send a cross-origin request
2. Browser sends OPTIONS first
3. Server replies with allowed methods/headers/origins
4. Browser decides whether to continue

Example of a preflight-related response

A server may send headers like:

Access-Control-Allow-Origin: https://myfrontend.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

That tells the browser what is allowed.

Common situations where beginners hit CORS

1. Frontend and backend are on different ports locally

Example:

• frontend: http://localhost:3000
• backend: http://localhost:8000

Those are different origins because the ports are different.
So CORS rules still apply.

2. Calling a third-party API directly from the browser

Some APIs do not allow browser access from random websites.
They may expect requests to come from your backend instead.

3. Sending credentials without proper server support

If cookies or authenticated requests are involved, the server needs a more careful CORS setup.
You cannot combine every option freely.

Common beginner mistakes

1. Thinking CORS is a backend bug every time

Sometimes it is a backend configuration issue.
But sometimes the API is intentionally blocking browser access.
That may be the correct behavior.

2. Thinking Access-Control-Allow-Origin: * solves everything

It does not.
Especially not when credentials are involved.
This is one of those "works until it absolutely does not" ideas.

3. Trying to fix CORS only on the frontend

Usually, the real fix is on the server that owns the resource.
Your frontend cannot simply decide that another server should trust it.

4. Forgetting the difference between browser code and server code

If your backend makes the request, browser CORS rules usually are not the thing blocking you.
If your frontend makes the request in the browser, they are.

So how do developers usually fix CORS?

The usual answer is one of these:

• configure the backend to allow the frontend origin
• use the correct CORS middleware in the backend framework
• make the request through your own backend instead of directly from the browser
• handle preflight requests correctly

For example, many frameworks have built-in CORS packages or middleware.
You define which origins, methods, and headers are allowed.

A practical mental model to remember

When you see a CORS error, ask these questions:

1. Who is making the request? The browser or the server?
2. Are the origins different? Domain, protocol, or port?
3. Does the server send the right CORS headers?
4. Is there a preflight request failing first?

That short checklist saves a lot of confused guessing.

Final takeaway

If you remember only one thing, let it be this:

CORS is the browser's way of enforcing rules about which websites are allowed to read responses from another origin, based on what the server permits.

Once that clicks, CORS errors stop feeling like cursed magic and start looking like a configuration problem you can reason about.