CORS Explained Simply — Why Your Fetch Works in Postman but Fails in the Browser

Your API works in Postman. Same URL, same headers, same body.
Open the app in Chrome → red error in the console:

Access to fetch at 'https://api.example.com/users' from origin 'https://app.example.com'
has been blocked by CORS policy...

Nothing is "broken" on the server. The browser is doing its job.

CORS is not a server bug — it's a browser security rule.
Postman doesn't enforce it. Browsers do.

Once you understand that one line, CORS stops feeling random.

🧠 What Problem Does CORS Solve?

Browsers enforce the Same-Origin Policy:

JavaScript on https://app.example.com should not silently read data from https://bank.com.

An origin = protocol + domain + port:

https://app.example.com:443
  ↑        ↑              ↑
protocol  host          port

These are different origins:

Without CORS, any website could fetch() your logged-in session from another domain and steal data.

CORS is the mechanism that lets a server say:

"Yes, I allow https://app.example.com to read my responses in the browser."

🔍 Simple Request vs Preflight

Not every cross-origin request triggers a preflight. The browser decides.

Simple request (no preflight)

Usually:

• Methods: GET, HEAD, POST
• "Safe" headers only (Accept, Content-Type like text/plain, application/x-www-form-urlencoded, multipart/form-data)
• No custom headers like Authorization

Browser → GET https://api.example.com/users
Server  → 200 + Access-Control-Allow-Origin: https://app.example.com
Browser → ✅ JS can read the response

Preflight request (OPTIONS first)

Happens for most modern APIs:

• Methods: PUT, PATCH, DELETE
• Custom headers: Authorization, X-API-Key
• Content-Type: application/json

1. Browser sends OPTIONS — "Can I do this?"
2. Server responds with allowed origin, methods, headers
3. If allowed → browser sends the real request
4. If not → browser blocks before your fetch even runs

You'll see two requests in DevTools Network tab. That's normal.

📋 The Headers That Matter

Server → Browser (response)

Browser → Server (preflight request)

🍪 Cookies & Credentials

Cross-origin fetch does not send cookies by default.

fetch("https://api.example.com/me", {
  credentials: "include", // send cookies
});

Server must respond with:

Access-Control-Allow-Origin: https://app.example.com   ← exact origin, NOT *
Access-Control-Allow-Credentials: true

⚠️ Allow-Origin: * + credentials = blocked. Browsers reject that combo.

This connects to HttpOnly cookies — session auth across origins needs careful CORS + cookie config (SameSite, Secure, correct domain).

❌ Common Errors & Fixes

1. "No Access-Control-Allow-Origin header"

Meaning: Server didn't grant permission (or error response omitted CORS headers).

Fix: Add CORS headers on the API server for successful and error responses.

// Express example
app.use((req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", "https://app.example.com");
  res.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
  res.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");
  next();
});

2. Preflight fails (OPTIONS returns 404 or 401)

Meaning: Server doesn't handle OPTIONS, or auth middleware blocks it.

Fix: Respond to OPTIONS before auth middleware:

app.options("*", (req, res) => {
  res.sendStatus(204);
});

3. "Header Authorization is not allowed"

Fix: Include it in Access-Control-Allow-Headers.

4. Works locally, fails in production

Different origins in dev vs prod:

Dev:  http://localhost:3000  →  https://api.staging.com
Prod: https://app.com        →  https://api.com

Whitelist both origins (or use env-based config).

5. "I'll fix it with a CORS browser extension"

That only fixes your machine. Not users. Not interviews. Fix the server or proxy.

🛠️ Frontend Fixes That Actually Work

Option A: Fix CORS on the API (correct for public APIs)

The API owner adds proper headers. Required when third-party frontends call your API.

Option B: Same-origin proxy (common in Next.js)

Browser calls your domain; server forwards to the API. No cross-origin from browser's view.

// app/api/users/route.ts (Next.js App Router)
export async function GET() {
  const res = await fetch("https://api.example.com/users", {
    headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
  });
  return Response.json(await res.json());
}

// Client — same origin, no CORS issue
fetch("/api/users");

✅ Hides secrets (API keys stay on server)
✅ Avoids browser CORS entirely
✅ Pattern used in most production Next.js apps

Option C: Server-side fetch only

RSC / getServerSideProps / Server Actions fetch external APIs on the server — CORS doesn't apply server-to-server.

🚫 Myths (Interview Gold)

🔬 How to Debug in 60 Seconds

1. Open DevTools → Network
2. Find the failing request (often OPTIONS in red)
3. Check Response Headers — is Access-Control-Allow-Origin present?
4. Compare Request Headers → Origin with what server allows
5. If OPTIONS fails → fix preflight before touching the real endpoint

🎯 Interview Cheat Sheet

✅ Decision Guide

Fetch from browser to different origin?
├── Public API you control → add CORS headers on API
├── Private API / secret keys → Next.js API route proxy
├── Server Component / SSR → fetch on server (no CORS)
└── Dev-only hack (extension) → ❌ not a solution

✨ Final Takeaway

CORS is the browser asking the server: "Is this web app allowed to read your response?"
If the server doesn't say yes with headers, the browser hides the data — even if the API returned 200.

Postman never asks that question. Your users' browsers always do.

Learn to read the Network tab, fix headers or proxy through your backend, and this error stops wasting your afternoons.

Suggested follow-ups

• HttpOnly Cookies — auth, cookies, and cross-origin pitfalls
• CDN Explained in Next.js — caching at the edge (different from CORS, often confused)
• AbortController — cancel fetch requests cleanly