CORS Misconfiguration in Vibe-Coded Apps: Wildcard Origins Explained

What CORS Actually Does

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that restricts which origins can call your API from JavaScript running on a different domain. Without CORS headers, a script on evil.com cannot fetch data from yourapp.com/api/users - the browser blocks it. When you add Access-Control-Allow-Origin: *, you instruct the browser to lift that restriction for every origin on the internet.

The distinction that matters: CORS is enforced by browsers, not servers. Direct server-to-server requests, curl, and tools like Postman bypass CORS entirely. What CORS protects is the response: it stops a malicious website from reading your API's data through a logged-in user's browser. It does not stop a simple request from reaching your server, which is why CSRF needs its own defenses.

The OWASP API Security Top 10 (2023) lists a missing or improperly set CORS policy under API8, Security Misconfiguration.

How AI Tools Generate Wildcard CORS

When you ask Cursor, Bolt, or Lovable to "add CORS support to my Express API," the generated code often looks like this:

// ❌ BAD - Wildcard CORS that allows any origin
const express = require('express');
const cors = require('cors');

const app = express();

// AI-generated: "allows all origins" - dangerous in production
app.use(cors());
// Equivalent to:
// app.use(cors({ origin: '*' }));

app.get('/api/user/profile', async (req, res) => {
  const userId = req.session.userId;
  const user = await db.user.findUnique({ where: { id: userId } });
  res.json(user);
});

Calling cors() with no arguments is equivalent to setting Access-Control-Allow-Origin: *, and it answers preflight requests from any domain. Any website can then read every response your API gives to a request made without credentials. Browsers will not share a cookie-authenticated response with a wildcard origin, so the bigger risk comes when someone "fixes" that.

The Credentials Combination Makes It Critical

Wildcard CORS alone is bad. An API that reflects whatever Origin it receives and also sends Access-Control-Allow-Credentials: true is a critical vulnerability. Browsers block credentialed responses that come back with Access-Control-Allow-Origin: *, so when you prompt an AI tool to "fix CORS errors with authentication," it may switch to reflecting the origin, for example cors({ origin: true, credentials: true }). Then any website can read a logged-in user's data.

// ✅ GOOD - Explicit allowlist of permitted origins
const allowedOrigins = [
  'https://yourapp.com',
  'https://www.yourapp.com',
  process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : null,
].filter(Boolean);

app.use(cors({
  origin: (origin, callback) => {
    // Allow requests with no origin (curl, Postman, server-to-server)
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error(`CORS: origin ${origin} not allowed`));
    }
  },
  credentials: true,         // Only safe with an explicit origin list
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
}));

In Next.js, CORS is configured per-route in the route.ts handler or globally via next.config.js headers. Next.js Proxy (called middleware before Next.js 16) is also a place to enforce an origin allowlist before requests reach your route handlers.

CORS Misconfiguration Patterns to Watch For

CORS in Supabase and Vercel Deployments

Supabase's hosted API already has its own CORS configuration, but when you add a Next.js or Express backend layer in front of Supabase - a common Bolt and Lovable architecture - that layer needs its own CORS policy. The Supabase client configuration on the frontend does not protect the middleware layer.

Vercel deployments support CORS header configuration in vercel.json. A wildcard header there is added to every matching response, including routes where your application deliberately left the header off to reject an origin. Always audit your vercel.json headers block when deploying to Vercel. A common AI-generated pattern is:

// ❌ BAD - vercel.json wildcard that bypasses app-level CORS
{
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [{ "key": "Access-Control-Allow-Origin", "value": "*" }]
    }
  ]
}

This single configuration change can undo application-level origin validation across every API route in the project.

How to Find CORS Misconfigurations

A targeted search covers most cases. Look for cors() called without arguments, Access-Control-Allow-Origin set to a string literal "*", and any place where the incoming Origin header is reflected directly back without validation. In Next.js, check both next.config.js headers and individual route.ts files for response header assignments.

Tools like VibeDoctor's Vibe Check automatically flag explicit wildcard or reflected origins (origin: '*', origin: true, an Access-Control-Allow-Origin: * header) in JavaScript and TypeScript, and wildcard settings in Flask-CORS, FastAPI, and Django, with specific file paths and line numbers. A bare cors() call and vercel.json are not checked, so search for those yourself. Free to sign up.

FAQ