Cross-origin request blocked means the browser prevented a web page from fetching a resource from a different origin (scheme, domain, or port) due to the same-origin policy.
What "Cross-origin request blocked" Means
The browser enforces the same-origin policy to protect users from malicious sites reading sensitive data from other sites. When your code makes an HTTP request to a different origin than the one serving the page, the browser blocks the response unless the server explicitly allows it via CORS headers. This error appears in the console as something like Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000' has been blocked by CORS policy.
Why It Happens
The most common cause is a missing or incorrect Access-Control-Allow-Origin header on the server response. A second cause is preflight failures — when your request uses non-simple headers (like Authorization or Content-Type: application/json), the browser sends an OPTIONS request first, and if the server doesn't respond correctly, the actual request never fires. A third cause is mismatched origins: your frontend runs on http://localhost:5173 but the API lives on http://localhost:8000 — different ports count as different origins.
Example Code That Triggers It
Here's a minimal Next.js API route that triggers this exact error when called from a client component on a different port:
// app/api/data/route.ts (Next.js 14+)
export async function GET() {
return Response.json({ message: "Hello" });
}
And the client-side fetch that gets blocked:
// app/page.tsx
const res = await fetch("http://localhost:8000/api/data");
const data = await res.json();
If the Next.js app runs on port 3000 and the API on 8000, the browser blocks the response because the server doesn't send CORS headers.
How to Fix It
The correct fix is to add CORS headers on the server. For a Node.js/Express API, it looks like this:
import express from "express";
const app = express();
app.use((req, res, next) => {
res.setHeader("Access-Control-Allow-Origin", "http://localhost:3000");
res.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
res.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");
if (req.method === "OPTIONS") return res.sendStatus(204);
next();
});
app.get("/api/data", (req, res) => {
res.json({ message: "Hello" });
});
The fix works because the browser sees the Access-Control-Allow-Origin header matching the requesting origin, so it permits the response. For production, use a package like cors or configure CORS in your hosting platform (Vercel, Netlify, or your reverse proxy) rather than hardcoding origins.
Common Mistakes That Cause This
The first mistake is using Access-Control-Allow-Origin: * with credentials — browsers reject wildcard origins when credentials: "include" is set. The second mistake is forgetting the preflight OPTIONS handler entirely; most servers return 404 for OPTIONS, which silently kills the real request. I've also seen developers try to fix CORS on the client side with mode: "no-cors", which only hides the error and returns an opaque response you can't read.
When Should You Worry About This?
You should worry when you're building a public API consumed by third-party apps — you must explicitly whitelist origins or you'll block legitimate clients. For internal microservices behind a gateway, you often don't need CORS at all since requests go server-to-server. And if you're using Next.js API routes as a proxy, you can avoid CORS entirely by fetching from your own backend and forwarding the request server-side — this is the cleanest pattern for full-stack apps.
What to Check First
Check the server's response headers in the Network tab — if Access-Control-Allow-Origin is missing or doesn't match your exact origin (including the port), that's your root cause, not your client code.