Fix CORS Policy Errors on API Endpoints Fast

You got the CORS error. I get it.

You're building an app. You call your API from the frontend. And bam — Access to fetch at 'https://api.yoursite.com/data' from origin 'https://app.yoursite.com' has been blocked by CORS policy. It's infuriating because your endpoint works fine in Postman. I've been there. The fix is simpler than you think.

Step 1: Add the CORS headers server-side

The browser blocks the request because your server doesn't send the right headers. You need to add this to your API endpoint response:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

That's the minimum. If you're using a framework, it's easier.

For Node.js (Express)

const cors = require('cors');
app.use(cors({ origin: 'https://app.yoursite.com' }));

Use the specific origin instead of * in production. It's safer. I've seen people use * and then wonder why cookies don't work — you can't use * with credentials.

For .NET Core

app.UseCors(policy => policy.WithOrigins("https://app.yoursite.com")
    .AllowAnyMethod().AllowAnyHeader());

Put this in Program.cs or Startup.cs before the UseRouting() call. Order matters in .NET — I've wasted hours on this.

Step 2: Handle OPTIONS preflight requests

The browser sends an OPTIONS request before the actual GET or POST. This is the preflight. Your server must respond to it with the CORS headers. If you're using a framework, it handles this automatically. But if you have a custom server or a serverless function (like AWS Lambda), you need to do it manually.

Here's a generic handler for any server:

if (request.method === 'OPTIONS') {
  response.setHeader('Access-Control-Allow-Origin', 'https://app.yoursite.com');
  response.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
  response.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  response.status(200).end();
}

If you skip this, the browser never sends the real request. I've seen developers spend hours debugging their GET endpoint when the real problem is the OPTIONS handler.

Step 3: Check your API gateway or reverse proxy

If you use Nginx, Apache, or a cloud API gateway (like AWS API Gateway or Cloudflare), CORS headers can be stripped or added at that level. For example, in AWS API Gateway, you must enable CORS in the gateway settings and in your Lambda response. I've seen this double-config trip up many people — the gateway adds its own headers, but the Lambda also sends them, causing conflicts.

My rule: pick one layer to handle CORS. Either the gateway or the app, not both. I prefer the app layer because it gives you more control over origins.

Less common variations that still bite you

Multiple origins

You can't use Access-Control-Allow-Origin: * with credentials. If you need multiple origins, you have to check the Origin header in the request and return the matching one. Here's a pattern:

const allowedOrigins = ['https://app1.com', 'https://app2.com'];
const origin = request.headers.origin;
if (allowedOrigins.includes(origin)) {
  response.setHeader('Access-Control-Allow-Origin', origin);
}

Credentials (cookies, auth headers)

If you're sending cookies or custom auth headers, you need to add Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin must NOT be *. Also, the client must set credentials: 'include' in the fetch call.

Non-standard HTTP methods (PUT, DELETE, PATCH)

If your API uses PUT or DELETE, make sure they're listed in Access-Control-Allow-Methods. Some frameworks only include GET and POST by default.

How to prevent CORS errors in the future

• Use environment-specific CORS configs. In development, allow http://localhost:3000. In production, use your real domain. I use a config file that switches based on NODE_ENV or ASPNETCORE_ENVIRONMENT.
• Test the OPTIONS endpoint. I run curl -X OPTIONS https://api.yoursite.com/data -H "Origin: https://app.yoursite.com" -v to check headers before I touch the browser.
• Log the CORS headers in your server or gateway for debugging. I add a quick log in the middleware that prints the origin and the response headers. Saves hours when things break.
• Don't use wildcard origins in production. It's lazy and blocks cookie-based auth. You'll regret it.

CORS errors are just the browser being a gatekeeper. Once you set the headers right on the server, the browser stops screaming. I've fixed hundreds of these — the fix is always on the server or the proxy, never the client. Good luck.