Fix CORS Errors That Work on Localhost But Break in Production (MERN)

A practical guide to why CORS breaks only after deployment, with exact Express.js fixes for credentials, cookies, and cross-domain preflight requests.

If your MERN app works perfectly on localhost but throws Access to fetch has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present the moment you deploy, your backend's CORS config is hardcoded for a dev environment that no longer exists in production.

Why It Works Locally But Not in Production

Locally, many devs run frontend and backend close enough (same port, proxy config, or browser extensions disabled) that CORS restrictions barely surface. In production, your frontend is usually on https://myapp.com and your API is on https://api.myapp.com or a separate host like Render/Railway entirely — a genuine cross-origin request, so the browser enforces the full CORS handshake.

Root Causes, Ranked by Frequency

• 🌐 origin in your CORS config is still set to http://localhost:3000
• 🍪 Using credentials: true on the frontend but Access-Control-Allow-Origin: * on the backend (invalid combination)
• 🔒 Cookies not sent because SameSite/Secure flags aren't set for a cross-domain setup
• 🚧 Preflight OPTIONS requests never reaching your CORS middleware (blocked by a proxy, load balancer, or route order)

Fix 1: Set the Correct Origin Per Environment

Never hardcode a single origin. Use an environment variable so dev and prod each get the correct value, and allow multiple origins if you have staging/preview deployments.

import cors from "cors";

const allowedOrigins = [
  "http://localhost:3000",
  "https://myapp.com",
  "https://staging.myapp.com",
];

app.use(
  cors({
    origin: (origin, callback) => {
      if (!origin || allowedOrigins.includes(origin)) {
        callback(null, true);
      } else {
        callback(new Error("Not allowed by CORS"));
      }
    },
    credentials: true,
  })
);

Fix 2: Never Combine Wildcard Origin With Credentials

The browser will reject the response outright if Access-Control-Allow-Origin: * is paired with a credentialed request. If you need cookies or auth headers sent cross-origin, you must echo back a specific origin.

// ❌ Invalid with credentials
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

// ✅ Valid: specific origin + credentials
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Credentials: true

// Frontend fetch must also opt in:
fetch("https://api.myapp.com/data", {
  credentials: "include",
});

Fix 3: Cookie SameSite and Secure Flags

If your frontend and API are on different subdomains or domains, cookies set with the default SameSite=Lax will silently fail to be sent on cross-site requests.

res.cookie("token", jwtToken, {
  httpOnly: true,
  secure: true,        // required in production (HTTPS)
  sameSite: "none",    // required for cross-domain requests
});

Fix 4: Make Sure CORS Middleware Runs Before Your Routes

If app.use(cors()) is placed after your route handlers, or after another middleware that terminates the request, the preflight OPTIONS request never gets the right headers.

const app = express();

// ✅ CORS must be one of the very first middleware
app.use(cors({ origin: allowedOrigins, credentials: true }));
app.use(express.json());

// routes go after
app.use("/api/users", userRoutes);

Diagnostic Checklist

Official-Style Error Explanation

No 'Access-Control-Allow-Origin' header is present on the requested resource indicates the server's response did not include the required CORS header for the requesting origin. This is a server-side configuration issue, not a frontend bug. Configure the backend to explicitly allow the production origin and retry the request.

Frequently Asked Questions

---

CORS errors in production almost always trace back to an origin, credentials, or cookie-flag mismatch between environments — fix the config once per environment and it stays fixed.