How to Fix CORS Errors in AI-Generated Apps

CORS (Cross-Origin Resource Sharing) is a browser security mechanism, not a server error. Here’s how it works: whenever your application tries to send an HTTP request to a different origin (a different domain, port, or protocol), the browser first asks the target server whether this is allowed.

On localhost, your frontend and backend usually run at the same address — for example http://localhost:3000. That’s same-origin — same domain, same port, same protocol. The browser sees no issue because the request goes to the same host. This is why everything works during development.

After deployment, your frontend lives at https://myapp.com and your backend at https://api.myapp.com or an entirely different domain. That’s cross-origin. And this is where the browser steps in.

Before the browser sends your actual request (POST, PUT, DELETE), it first sends a so-called preflight request — an OPTIONS request to the same URL. It’s essentially asking: “Hey server, is the frontend from domain X allowed to send POST requests with these headers?” If the server doesn’t respond with the right CORS headers, the browser blocks the request before it’s even sent.

The key thing to understand: CORS is a browser mechanism. Postman, curl, server-to-server requests — none of them enforce CORS. That’s why your API can work perfectly in Postman while throwing errors in the browser. It’s not an API bug — it’s the browser doing its job.

Step 1: Check the real error

Most people look at the CORS error in the browser console and assume it’s a CORS problem. But often the real error is elsewhere. Open the Network tab in DevTools, not Console.

Find the failed request. Click on it and check the response code. If you see 500 Internal Server Error, your server crashed — and because it crashed, it didn’t add CORS headers to the response. The browser sees the missing Access-Control-Allow-Origin header and shows a CORS error, but the real problem is a server error.

If the endpoint errors out (500), Access-Control-Allow-Origin usually won’t be added. Fix the server error, and the “CORS error” will disappear on its own.

Step 2: The RIGHT way to configure CORS (Express.js)

Here’s what a CORS middleware should look like on an Express.js server. Notice that it sets specific domains instead of wildcards, handles the OPTIONS request, and sets credentials:

const allowedOrigins = ['https://yourapp.com', 'https://app.yourapp.com'];

function corsMiddleware(req, res, next) {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Methods',
      'GET, POST, PUT, DELETE, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers',
      'Content-Type, Authorization');
    res.setHeader('Access-Control-Allow-Credentials',
      'true');
  }
  if (req.method === 'OPTIONS')
    return res.status(204).end();
  next();
}

Step 3: What AI generates (wrong)

And here’s what AI typically generates when you ask it to “fix CORS.” It looks simple, but it’s full of problems:

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', '*');
  next();
});
// No OPTIONS handling
// Wildcard in production
// No credentials support
// No Allow-Methods or Allow-Headers

The differences are critical: the wildcard * means any website in the world can send requests to your API. No OPTIONS handling means preflight requests won’t work. No Allow-Credentials means cookies and tokens won’t be sent. This isn’t “fixed” — it’s an open security hole.

Step 4: CORS in Supabase Edge Functions

If you’re using Supabase Edge Functions (Deno), CORS must be handled manually in each function — or, even better, centralized in a single helper file. Here’s the correct pattern:

const corsHeaders = {
  'Access-Control-Allow-Origin': 'https://yourapp.com',
  'Access-Control-Allow-Methods': 'POST, OPTIONS',
  'Access-Control-Allow-Headers':
    'Content-Type, Authorization',
};

Deno.serve(async (req) => {
  if (req.method === 'OPTIONS')
    return new Response(null, {
      status: 204,
      headers: corsHeaders
    });

  // Your logic here
  const data = { message: 'Hello' };

  return new Response(
    JSON.stringify(data),
    {
      headers: {
        ...corsHeaders,
        'Content-Type': 'application/json'
      }
    }
  );
});

Step 5: Centralize CORS configuration

One file, one place. CORS configuration should live in one place across your entire project — not scattered across every endpoint and every function. Create a cors.js (or cors.ts) file and import it everywhere it’s needed.

At the same time, lock down your JSON response shape — every endpoint should return data in the same format. Keep your entry file tiny — it should only import middleware and start the server. All business logic goes into separate files.

This way, when you need to change allowed origins or add a new header, you do it in one place, and the change works everywhere. Lack of centralization is one of the main reasons AI apps work locally but fail in production.

Step 6: Debug tricky cases

Sometimes everything looks correct and CORS still doesn’t work. Here are the most common traps:

• URL mismatches: https://myapp.com is not the same as https://www.myapp.com. Watch out for trailing slashes — the browser sends the Origin header without a trailing slash, so if your allowlist includes https://myapp.com/, the string comparison will fail.
• no-cors mode in fetch: If someone (or AI) added mode: 'no-cors' to a fetch request, the browser won’t throw an error — but the response will be “opaque.” You can’t read the status, headers, or body. This isn’t a fix — it’s sweeping the problem under the rug.
• Mixing HTTP and HTTPS: http:// and https:// are different origins. If your frontend is on HTTPS and your backend on HTTP, CORS will block the request, and on top of that the browser may block mixed content.
• Dev proxy vs. production: Many frameworks (React, Vue, Next.js) use a proxy in development mode that masks cross-origin requests. In production, that proxy doesn’t exist — and suddenly CORS explodes. That’s why CORS errors only show up after deployment.

Before you deploy your application, go through these points. Each one is a potential source of CORS errors in production. If one is unmet, your app may break in ways that are hard to diagnose.