CORS Set to Wildcard: How AI Tools Leave Your Cookie-Based Auth Wide Open

Your API accepts requests from any website on the internet, and it still trusts the cookie in the browser to prove who you are.

This is a CORS misconfiguration, and it's one of the most common mistakes AI tools make. You hit a CORS error while testing locally. You ask the AI to fix it. It adds a wildcard origin, the error goes away, and you move on. Nobody checks what that wildcard actually allows.

Here's why it's dangerous. If your app uses cookies to keep users logged in, the browser attaches that cookie automatically on any request to your domain, even one triggered by a page on a totally different site. CORS is the only thing stopping that other site from reading the response. Set the origin to *, and you remove the one guard rail that was doing that job.

Here's what the broken version looks like:

app.use(cors({
  origin: '*',
  credentials: true,
}));

Most frameworks will actually throw an error here, because browsers block wildcard origins when credentials are involved. So the AI works around it. It reflects whatever origin sent the request back as the allowed origin, which does the same damage without tripping the built-in check.

app.use(cors({
  origin: (origin, callback) => callback(null, true),
  credentials: true,
}));

Now picture a user logged into your app in one tab. They visit evil-site.com in another tab. That site sends a background request to your API. The browser attaches the user's session cookie automatically. Your server sees a valid cookie, treats the request as trusted, and hands the response straight back to the attacker's page.

Here's the fix. List the exact origins your app runs on, and nothing else:

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

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

A request from anywhere else gets rejected before your server does anything with the cookie.

A few things worth checking beyond the main fix. Make sure your allowed origins list doesn't include localhost in production. Make sure you're not trusting an Origin header pattern like *.yourapp.com unless you're certain no one else can register a matching subdomain. And if your app doesn't need cookies for auth at all, consider switching to a bearer token in an Authorization header instead. Tokens aren't sent automatically by the browser, so this entire class of bug goes away.

To check your own app, open your server code and search for cors(. Look at what origin value it's set to. If it's *, or a function that returns true for any origin, and your app also sets credentials: true or reads a session cookie, you have this bug. You can also open your browser's dev tools, go to the Network tab, and check the Access-Control-Allow-Origin header on an API response. If it echoes back an origin you never listed, or shows a wildcard next to a Set-Cookie header, that confirms it.

If you want someone else to check this for you, get a free assessment. We'll review your app's CORS setup and auth flow and tell you exactly what's exposed, within 24 hours.

VibeAudits audits apps built with Cursor, Lovable, Bolt, Claude Code, Replit, and other AI tools.