Md Kashif Raza Khan
••4 min read
.NET CORS – What It Really Is and Why It Annoys Developers at First
If you have ever connected a .NET API with Angular, React, or even a simple PHP frontend, chances are you didn’t learn CORS first.
You met it as an error.
Most developers do.
You run the frontend, call the API, everything looks fine in Postman…
and then the browser throws a big red message saying the request is blocked.
That’s CORS.
So… what is CORS actually?
CORS means Cross-Origin Resource Sharing.
In very simple words:
it’s a browser rule that decides which website is allowed to talk to your API.
If the frontend and backend are not coming from the same place (domain, port, or protocol), the browser pauses and asks:
“Should I allow this request or not?”
If your API doesn’t answer properly, the browser blocks it.
Why does CORS exist at all?
Because without it, the internet would be unsafe.
Imagine:
You log in to a website
Your browser stores cookies or tokens
Another random site secretly calls the same API
Without CORS, that request could go through.
So browsers follow a rule called Same-Origin Policy:
Same domain → allowed
Same protocol → allowed
Same port → allowed
Anything different needs explicit permission.
That permission is CORS.
A very common real-world case
Frontend:
http://localhost:4200 (Angular)
Backend:
https://localhost:5001 (.NET API)
Ports are different → browser blocks it.
That’s when developers see:
No ‘Access-Control-Allow-Origin’ header is present
The API is working.
The browser just refuses to accept the response.
Why CORS is actually useful (even if it feels annoying)
Stops unknown websites from using your API
Protects logged-in users
Forces you to be clear about who can access your backend
Required for modern frontend frameworks
Once configured properly, you rarely touch it again.
How to allow CORS in .NET (the clean way)
First, add CORS in Program.cs:
builder.Services.AddCors(options =>
{
options.AddPolicy("AllowFrontend", policy =>
{
policy.WithOrigins(
"http://localhost:4200",
"http://localhost:3000",
"http://localhost:8080"
)
.AllowAnyHeader()
.AllowAnyMethod();
});
});
Then enable it:
app.UseCors("AllowFrontend");
One important thing developers miss:
CORS middleware order matters.
Put it after routing and before authorization.
Common local ports developers use
You usually see these during development:
Angular → 4200
React → 3000
Vue → 8080
Next.js → 3000
PHP (XAMPP) → 80 or 8080
Node / Express → 3000
.NET API → 5000 / 5001
Ionic → 8100
If your frontend runs on any of these, the exact port must be allowed.
Types of CORS requests (quick idea)
There are two main cases:
Simple requests
Mostly GET or basic POST.
They usually work without much trouble.
Preflight requests (OPTIONS)
Used for PUT, DELETE, custom headers, or auth.
The browser first asks the API:
“Are you okay with this request?”
If OPTIONS fails, everything fails.
This is where most CORS bugs live.
Problems developers face again and again
1. Works in Postman but not in browser
Postman doesn’t follow browser security rules.
So CORS never shows there.
Always test in the browser.
2. OPTIONS request blocked
Usually happens because:
CORS is not enabled globally
Middleware order is wrong
Fixing middleware order solves half of CORS issues.
3. Credentials error (cookies or auth)
When using credentials, you cannot allow all origins.
You must specify exact origins.
Wildcard doesn’t work here.
4. Production works but local fails (or the opposite)
Most of the time:
Wrong protocol
Missing port
Domain mismatch
CORS is very strict.
Even a small mismatch breaks it.
Simple best practices that save time
Never allow all origins in production
Always whitelist exact frontend URLs
Keep dev and production CORS separate
Remember: CORS is browser-side protection, not API security
If something breaks suddenly, check ports first
Final words
CORS feels like an enemy when you first meet it.
Later, it feels more like a security guard doing their job.
Once you understand why it exists, debugging becomes much easier.
And after a few projects, configuring CORS becomes muscle memory — no stress, no panic, no random fixes.
M
Md Kashif Raza Khan
Technical writer and software development expert at Murmu Software Infotech, sharing insights on modern web development, software architecture, and best practices.