DEV Community: Charles Kern

3 Auth Bugs Cursor Keeps Writing Into Your API Endpoints

Charles Kern — Sat, 18 Apr 2026 16:35:34 +0000

TL;DR

AI editors write protected routes with zero auth middleware
jwt.decode() is not jwt.verify() -- the difference lets attackers forge tokens
Login endpoints with no rate limiting can be brute-forced in seconds

I've been reviewing AI-generated Node.js backends for the past couple of months. The vulnerability that keeps appearing isn't SQL injection or hardcoded secrets. It's broken auth. Three specific patterns, repeated across every project I've looked at.

None of these are flashy. The code runs fine. It just runs insecurely.

No auth middleware on protected routes (CWE-306)

Cursor writes this constantly:

// bad -- CWE-306: Missing authentication
app.get('/api/users/:id', async (req, res) => {
  const user = await User.findById(req.params.id);
  res.json(user);
});

No middleware. No token check. Any unauthenticated request returns the full user record.

The AI saw thousands of tutorial routes that skip auth to focus on the main teaching point. It learned the default pattern.

The fix adds an authenticate middleware and an ownership check:

const authenticate = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'Unauthorized' });
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch {
    return res.status(401).json({ error: 'Invalid token' });
  }
};

app.get('/api/users/:id', authenticate, async (req, res) => {
  if (req.user.id !== req.params.id) return res.status(403).json({ error: 'Forbidden' });
  const user = await User.findById(req.params.id);
  res.json(user);
});

The ownership check matters. Without it you fix the auth problem and introduce IDOR instead.

jwt.decode() is not jwt.verify() (CWE-347)

This one is subtle. AI often generates token handling code that reads the payload but skips signature verification:

// bad -- CWE-347: Improper verification of cryptographic signature
const payload = jwt.decode(token);
const userId = payload.sub;

jwt.decode() does zero cryptographic verification. It just base64-decodes the payload. An attacker can craft a token with any sub value they want, send it, and the application accepts it.

The fix is one word:

// good
const payload = jwt.verify(token, process.env.JWT_SECRET);
const userId = payload.sub;

jwt.verify() throws if the signature is invalid. That exception gets caught in your middleware and returns 401.

No rate limiting on login endpoints (CWE-307)

Every AI-generated login endpoint I've seen looks like this:

// bad -- CWE-307: No brute-force protection
app.post('/api/auth/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  const match = await bcrypt.compare(password, user.password);
  if (match) res.json({ token: generateToken(user) });
  else res.status(401).json({ error: 'Invalid credentials' });
});

Unlimited attempts. Even with bcrypt adding latency per check, a targeted attack against a known email can run through a wordlist in minutes.

Two lines of change:

// good
import rateLimit from 'express-rate-limit';

const loginLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 10 });

app.post('/api/auth/login', loginLimiter, async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  const match = await bcrypt.compare(password, user.password);
  if (match) res.json({ token: generateToken(user) });
  else res.status(401).json({ error: 'Invalid credentials' });
});

Why this keeps happening

AI editors train on code from tutorials, blog posts, and StackOverflow. Tutorials skip auth middleware to focus on the main point. Answers strip code down to the minimum viable snippet. The model absorbed millions of examples where middleware was left out.

It's not a flaw in the model's understanding of auth. It's a gap in the training distribution. Security patterns are underrepresented, and the model fills in defaults from whatever was most common in the data.

The fix is not better prompts. It's a scanner that runs at the moment code is generated.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags missing auth middleware, jwt.decode() misuse, and unprotected endpoints before I move on. That said, even a basic pre-commit hook with semgrep will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

Why Cursor Keeps Writing Prototype Pollution Into Your JS

Charles Kern — Fri, 17 Apr 2026 09:11:01 +0000

TL;DR

AI editors reproduce a dangerous recursive merge pattern from pre-2019 training data
The pattern lets attackers inject properties onto Object.prototype, poisoning every object in the process
Fix: use structuredClone() or key blocklist guards -- never accept recursive merges on untrusted input

I was reviewing a side project a colleague built with Cursor. Clean structure, sensible abstractions. Then I checked the config merge utility he'd dropped in.

function merge(target, source) {
  for (const key of Object.keys(source)) {
    if (typeof source[key] === 'object') {
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

Cursor wrote this. It's also the pattern that opened CVE-2019-10744 in lodash -- the same library used by millions of projects before the patch. The model doesn't know the pattern became dangerous. It just reproduces what worked in training data.

What the Exploit Looks Like

If that merge function touches any user-controlled input, an attacker sends this:

{ "__proto__": { "admin": true } }

After that call, every plain object in the process inherits admin: true. Your auth checks, your role comparisons, your conditional logic -- all of them now read from a poisoned prototype.

const user = {};
console.log(user.admin); // true -- you never set this

The object you created is clean. The prototype it reads from is not.

Why AI Keeps Generating This

The recursive merge pattern is plastered across training data. StackOverflow answers from 2014-2018, pre-patch lodash clones, hundreds of "deep merge in JavaScript" tutorials. The pattern worked perfectly before the security community understood prototype pollution. Now it lives in model weights, and there's no mechanism to mark it as deprecated-and-dangerous.

Prompt Cursor or Claude Code for "write a deep merge utility" and they reproduce this faithfully. It passes every unit test you write against normal inputs.

The Fix

Three safe options depending on your Node version:

// Option 1: structuredClone (Node 17+, strips prototype chain entirely)
const merged = structuredClone({ ...defaults, ...userInput });

// Option 2: JSON roundtrip (simple, strips prototype)
const merged = JSON.parse(JSON.stringify({ ...defaults, ...userInput }));

// Option 3: If you genuinely need recursive merge on internal config,
// add an explicit key blocklist (the lodash patch approach)
function safeMerge(target, source) {
  for (const key of Object.keys(source)) {
    if (key === '__proto__' || key === 'constructor' || key === 'prototype') continue;
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = target[key] || {};
      safeMerge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

If your Node version is 17+, structuredClone is the clean answer. No prototype chain, no blocklist to maintain.

Quick Audit Command

grep -rn "target\[key\]" src/ --include="*.js" --include="*.ts"
grep -rn "merge(" src/ --include="*.js" --include="*.ts"

If either hits on a recursive function that accepts external data, you have exposure. Worth running before your next deploy.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

Why Cursor Keeps Writing Wildcard CORS (And Why It Matters)

Charles Kern — Thu, 16 Apr 2026 05:44:19 +0000

TL;DR

AI editors default to app.use(cors()) -- allows every origin, always
The real risk hits when you add auth six days later and the CORS config never changes
Fix is eight lines but only matters if you apply it before credentials enter the picture

I shipped three side projects last year with Cursor doing the backend scaffolding. Every single one had the same CORS setup by the time I actually looked. Not because I asked for it explicitly -- because "set up CORS for my Express API" is the kind of prompt where AI defaults to the most permissive pattern it encountered during training.

The code runs. The frontend works. Nothing breaks. That is precisely why this one ships.

The vulnerable pattern (CWE-942)

// What Cursor generates for "add CORS to my Express app"
const cors = require('cors');
app.use(cors()); // no config = allow all origins, all methods, all headers

Or slightly more explicit but just as permissive:

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

For a stateless API -- no cookies, no Authorization headers -- wildcard CORS is mostly harmless. The problem is that real APIs do not stay stateless. You add JWT auth a week later. You drop in a session cookie. The CORS config stays where it is because it was working and nobody flagged it.

Now you have Access-Control-Allow-Origin: * on an authenticated API. Any site can make credentialed cross-origin requests to your endpoints. The browser spec actually blocks * with credentials: true -- but misconfigured apps often reach for origin: req.headers.origin as a "fix" for the browser error, which just shifts the problem from a wildcard to a reflected-origin setup. Reflected origin is arguably worse: it looks intentional.

Why AI keeps generating this

The pattern comes from the highest-voted Express CORS answers on Stack Overflow, written between 2016 and 2020. app.use(cors()) is the answer that solves the developer's immediate problem -- the browser CORS error -- with zero config. LLMs trained on this data reproduce it at high confidence because it works for the stated constraint.

There is no feedback loop. The AI does not know whether your API will need credentials later. It satisfies what you asked for.

The fix

const allowedOrigins = [
  'https://yourdomain.com',
  'http://localhost:3000' // remove before production
];

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

Two things to note. First, credentials: true is required if you're using cookies or Authorization headers cross-origin -- but the spec explicitly blocks origin: '*' combined with credentials: true, so you must use an explicit allowlist. Second, if your platform injects CORS headers at the edge (Cloudflare Workers, AWS API Gateway, Railway's proxy layer), your application-level config may be overridden or ignored. Check both layers.

The !origin check handles same-origin requests and server-to-server calls where Origin is not sent. Without it, your own backend-to-backend calls will fail in production.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

3 Prototype Pollution Bugs Cursor Keeps Writing Into Your Code

Charles Kern — Wed, 15 Apr 2026 17:10:34 +0000

TL;DR

AI editors generate deep-merge and object-spread patterns vulnerable to prototype pollution
Attackers inject proto properties to override Object defaults and bypass auth
Use Object.create(null), allowlists, or libraries with built-in prototype guards

Last week I was reviewing a side project a friend built entirely in Cursor. Express backend, MongoDB, the usual stack. The code looked clean. Linted. Tests passing. Then I spotted this in a settings endpoint:

function mergeConfig(target, source) {
  for (const key in source) {
    if (typeof source[key] === 'object') {
      target[key] = mergeConfig(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

That recursive merge has no guard against proto or constructor keys. It is textbook prototype pollution (CWE-1321).

Why AI editors keep writing this

The training data is the problem. StackOverflow is full of "how to deep merge objects in JavaScript" answers from 2015-2019 that use exactly this pattern. The top-voted answers predate any awareness of prototype pollution as an attack vector. LLMs reproduce what scored highest.

I asked Cursor to "write a function that deep merges two config objects" five times. Three out of five had no prototype guard. One used Object.assign (still vulnerable to shallow pollution). Only one used a library.

The pattern shows up in three common shapes:

Shape 1 -- Recursive merge with no key filter:

// CWE-1321: no __proto__ guard
function merge(target, source) {
  for (const key in source) {
    if (typeof source[key] === 'object') {
      target[key] = merge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

Shape 2 -- Express body parsed into config:

// CWE-1321: user input flows directly into object merge
app.put('/api/settings', (req, res) => {
  Object.assign(appConfig, req.body);
  res.json({ ok: true });
});

Shape 3 -- Spread into prototype-bearing objects:

// CWE-1321: spreading user input can override inherited properties
const userPrefs = { ...defaults, ...req.body };

What an attacker does with this

Send a JSON body like:

{"__proto__": {"isAdmin": true}}

Now every object in the process inherits isAdmin = true. Auth checks that rely on if (user.isAdmin) pass for everyone. Game over.

This is not theoretical. CVE-2019-10744 (lodash merge), CVE-2020-28498 (elliptic), CVE-2021-25928 (safe-obj) -- all prototype pollution. It is one of the most exploited vulnerability classes in Node.js.

The fix

Option A -- Allowlist keys explicitly:

const ALLOWED_KEYS = new Set(['theme', 'language', 'timezone']);

function safeMerge(target, source) {
  for (const key of Object.keys(source)) {
    if (!ALLOWED_KEYS.has(key)) continue;
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = safeMerge(target[key] || Object.create(null), source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

Option B -- Use Object.create(null) for config objects:

const config = Object.create(null); // no prototype chain

Option C -- Block dangerous keys:

const DANGEROUS = new Set(['__proto__', 'constructor', 'prototype']);
// skip any key in DANGEROUS during merge

Option D -- Use a safe library:
lodash.mergeWith (post-4.17.12 patch), deepmerge with customMerge, or structuredClone for simple cases.

I have been running SafeWeave to catch these. It hooks into Cursor and Claude Code as an MCP server and flags prototype pollution patterns before I move on. That said, even a semgrep rule targeting recursive merges with no hasOwnProperty check will catch the worst cases. The important thing is catching it early, whatever tool you use.

Why Cursor Skips Auth Middleware on Every Route It Generates

Charles Kern — Tue, 14 Apr 2026 15:06:06 +0000

TL;DR

AI editors consistently generate new routes without auth middleware, even when the rest of the codebase has it
CWE-862 (Missing Authorization) is one of the most common findings in vibe-coded Express and FastAPI backends
Fix: apply auth at router or app level -- never rely on AI to add it per-route

I've been reviewing side projects lately. Friends sending me "almost ready to ship" Node/Express apps built mostly with Cursor. Three out of four had the same problem. Fresh routes, zero auth middleware.

Not a single authenticate call. No requireAuth. Just wide-open handlers waiting for someone to enumerate user IDs.

The annoying part: the existing routes in the codebase had auth. The AI saw those. It just didn't carry the pattern forward to new endpoints it generated.

The Pattern That Keeps Showing Up

Here's what Cursor typically produces when you ask it to add a user data endpoint (CWE-862: Missing Authorization):

app.get('/api/users/:id/profile', async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json(user);
});

app.get('/api/users/:id/settings', async (req, res) => {
  const settings = await Settings.findOne({ userId: req.params.id });
  res.json(settings);
});

No auth check. No ownership check. Anyone who knows (or guesses) a user ID can read that user's profile and settings. The ID is often sequential or a predictable UUID -- IDOR waiting to happen.

Why AI Keeps Generating This

LLMs learn from tutorials and Stack Overflow. Most tutorial code shows the happy path -- getting a resource, returning it. Auth is always "added later," usually as a separate section.

The model sees thousands of routes without middleware for every one with it, especially in early-stage code examples. It defaults to omission over assumption because auth middleware is contextual -- it doesn't know if your middleware is called authenticate, requireLogin, or authGuard.

There's also a subtler issue: when you ask Cursor to "add a settings endpoint," you're framing a feature request. The AI answers that question. Auth wasn't part of the question.

The Fix

Apply auth at the router level, not per-route:

// Router-level middleware -- every route below this line is protected
const userRouter = express.Router();
userRouter.use(authenticate);

userRouter.get('/:id/profile', async (req, res) => {
  if (req.user.id !== req.params.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const user = await User.findById(req.params.id);
  res.json(user);
});

userRouter.get('/:id/settings', async (req, res) => {
  if (req.user.id !== req.params.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const settings = await Settings.findOne({ userId: req.params.id });
  res.json(settings);
});

app.use('/api/users', userRouter);

Or apply a global default-deny approach -- safer because new routes are protected automatically:

app.use((req, res, next) => {
  const publicPaths = ['/api/auth/login', '/api/auth/register', '/api/health'];
  if (publicPaths.includes(req.path)) return next();
  return authenticate(req, res, next);
});

With default-deny, you opt routes out of auth rather than opting them in. AI can generate all the routes it wants -- they're locked down until you explicitly open them.

Rate Limiting on Auth Endpoints

Missing auth is bad. Missing rate limiting on the login endpoint is worse. Here's what AI typically generates:

// No rate limiting -- brute force welcome
app.post('/api/auth/login', async (req, res) => {
  const user = await User.findOne({ email: req.body.email });
  const valid = await bcrypt.compare(req.body.password, user.password);
  if (!valid) return res.status(401).json({ error: 'Invalid credentials' });
  const token = jwt.sign({ id: user.id }, process.env.JWT_SECRET);
  res.json({ token });
});

Fix with express-rate-limit:

import rateLimit from 'express-rate-limit';

const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10,
  message: { error: 'Too many attempts, try again later' },
  standardHeaders: true,
  legacyHeaders: false,
});

app.post('/api/auth/login', authLimiter, loginHandler);
app.post('/api/auth/register', authLimiter, registerHandler);

Ten attempts per 15 minutes. Enough for legitimate users. Brute force becomes impractical.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

How to Fix Wildcard CORS in Cursor-Generated Code (CWE-942)

Charles Kern — Mon, 13 Apr 2026 13:01:03 +0000

TL;DR

Cursor and Claude Code default to cors() with no arguments in every Express scaffold
Wildcard CORS lets any origin read your API responses -- combine it with credentials and you have CWE-942
Fix: swap the wildcard for an explicit origin allowlist

I've reviewed maybe a hundred AI-generated Express backends in the last few months. CORS is misconfigured in almost every single one. Not subtly -- the default Cursor scaffold drops app.use(cors()) right below the imports and moves on. No allowlist. No origin validation. Just a wildcard.

For localhost demos this is fine. In production with any authentication layer, it's a problem.

The thing about cors() with no arguments is that it sets Access-Control-Allow-Origin: *. That alone isn't catastrophic -- browsers block credentialed cross-origin requests when the response includes a wildcard origin. So developers hit a CORS error in the browser, paste the error into Cursor, and Cursor "fixes" it by adding credentials: true. Now you have a genuine CWE-942: any origin can make a credentialed request and read your API response.

The Vulnerable Pattern

Cursor generates this at least half the time I scaffold a new route:

const cors = require('cors');
app.use(cors()); // CWE-942: Permissive Cross-Origin Resource Sharing

Or after the inevitable "why is CORS broken" follow-up:

app.use(cors({ origin: '*', credentials: true })); // invalid -- browser rejects wildcard + credentials

Which still breaks. So the next "fix" Cursor often suggests is reflecting the request origin:

app.use(cors({ origin: true })); // reflects any origin as-is -- completely open

That one works in the browser. It also means any site can read your API response after auth. Both the vulnerable pattern and the "fixed" version come from training data -- StackOverflow answers and tutorial code written to make the demo work, not to be secure.

Why This Keeps Happening

The GitHub corpus is full of Express tutorials where cors() with no args is the first line after app.listen. Optimized for "works in 30 seconds on localhost". That's the code AI editors absorbed.

CORS is also confusing enough that developers often don't push back on the AI's suggestion. The browser error message is opaque, the fix looks small, and when it "works" nobody asks what changed. The result is that CWE-942 ends up in codebases with real authentication, real user data, and nobody who remembers why the CORS config looks the way it does.

The Fix

Replace the wildcard with an explicit allowlist:

const allowedOrigins = [
  'https://app.yourdomain.com',
  process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : null,
].filter(Boolean);

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

The !origin check passes server-to-server requests and curl where there's no Origin header. Everything else has to be on the list. credentials: true is safe here because origin is validated before that setting applies.

For FastAPI:

# before (CWE-942)
app.add_middleware(CORSMiddleware, allow_origins=["*"], allow_credentials=True)

# after
origins = [os.getenv("FRONTEND_URL"), "https://app.yourdomain.com"]
app.add_middleware(
    CORSMiddleware,
    allow_origins=[o for o in origins if o],
    allow_credentials=True
)

Catch it before code review with a semgrep rule:

rules:
  - id: wildcard-cors
    patterns:
      - pattern: cors()
      - pattern: cors({ ..., origin: '*', ... })
    message: "Wildcard CORS (CWE-942). Use an explicit origin allowlist."
    severity: WARNING
    languages: [javascript, typescript]

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

IDOR in AI-Generated Code: The Auth Bug Cursor Keeps Missing

Charles Kern — Sun, 12 Apr 2026 11:04:36 +0000

TL;DR

AI editors generate API endpoints with authentication but no ownership checks
A logged-in user can fetch any other user's data by changing one number in the URL
Fix: always validate req.user.id === resource.userId before returning data

I reviewed a side project last month. Node/Express backend, Cursor-generated, looked clean. Real auth middleware. JWT tokens. Login worked fine. Then I changed the user ID in the URL to a different number. Different user's data came back. No error. No log entry.

The dev had no idea. Cursor flagged nothing. The endpoint had authentication -- just no authorization at the resource level.

This is IDOR: Insecure Direct Object Reference (CWE-639). It is not exotic. It is the most boring, most common authorization failure in AI-generated APIs, and it almost never gets caught before production.

The Pattern AI Keeps Generating

Ask any AI editor to write a "get user profile" endpoint and you get something like this:

// CWE-639: any authenticated user can fetch any profile
app.get('/api/users/:id', authenticate, async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json(user);
});

The authenticate middleware runs. The token is verified. The user is "logged in." But the endpoint returns any user's data for any valid ID. User 1 can fetch user 2's profile. User 2 can fetch user 100's orders. Every record in the database is one URL change away from exposure.

Why does AI generate this? Training data. Stack Overflow answers, GitHub tutorials, and "getting started" guides skip ownership checks in example code. The model learned from those examples. It reproduces the gap every time.

Why Standard Scanners Miss It

Authentication and authorization are different. Authentication: who are you? Authorization: what are you allowed to touch?

AI-generated code handles authentication correctly almost every time -- middleware, JWT validation, session checks, all generated properly. The gap is always at the resource level.

SAST tools look for SQL injection, XSS, missing crypto. They do not check business logic: "should this specific user be reading this specific record?" IDOR stays in the OWASP Top 10 year after year precisely because static analysis cannot catch it.

The Fix

Two parts: check ownership, return 403 when the check fails.

app.get('/api/users/:id', authenticate, async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });

  // ownership check -- the line AI always omits
  if (user._id.toString() !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  res.json(user);
});

Return 403, not 404. Returning 404 hides whether the record exists -- but it also makes your API silently lie. For admin routes where any authenticated user should access any record, add a role check instead of removing the ownership check entirely.

Python/FastAPI version:

@app.get("/api/users/{user_id}")
async def get_user(user_id: int, current_user: User = Depends(get_current_user)):
    user = await User.get(user_id)
    if not user:
        raise HTTPException(status_code=404)
    if user.id != current_user.id and current_user.role != "admin":
        raise HTTPException(status_code=403, detail="Forbidden")
    return user

Order matters. Fetch the resource first so you can compare IDs. Check ownership before returning.

Finding Existing IDOR Bugs in a Codebase

Grep for route handlers with dynamic parameters and no ownership check logic:

# Express -- routes that use :id params but never reference req.user
grep -rn "req.params.id" ./src --include="*.js" | grep -v "req.user"

# FastAPI -- route handlers with path params but no current_user comparison
grep -rn "async def get_" ./app --include="*.py" | grep -v "current_user.id"

These greps are rough. Any match is a candidate for manual review, not a confirmed bug. But on a 20-file backend, this takes 10 seconds and surfaces the ones worth looking at.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

Why Cursor Keeps Generating Wildcard CORS -- And How to Fix It

Charles Kern — Sat, 11 Apr 2026 15:11:15 +0000

TL;DR

AI editors almost always default to cors() with no config -- which sets Access-Control-Allow-Origin: *
Wildcard CORS on authenticated APIs exposes your users to cross-site request attacks
Fix: replace the wildcard with an explicit origin allowlist controlled by an env var

I was reviewing a side project a dev built entirely in Cursor. The Express backend looked clean -- structured routes, solid error handling, decent auth middleware. Then I checked the CORS setup.

app.use(cors()); // defaults to Access-Control-Allow-Origin: *

One line. Auto-suggested by Cursor from a starter template. Left in production because it made the frontend stop complaining in dev. Except this was prod.

Wildcard CORS feels harmless compared to SQL injection. No immediate data breach. But for any API using cookies or session tokens, a wildcard CORS config means any website -- a phishing page, a malicious ad iframe -- can make authenticated requests on behalf of your logged-in users without them knowing.

The vulnerable pattern (CWE-942)

Here's what Cursor and Claude Code almost always suggest when you ask for a working Express backend:

// CWE-942: Permissive Cross-domain Policy
const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors()); // Allows all origins -- no questions asked
app.use(express.json());

app.get('/api/user/profile', authenticate, (req, res) => {
  res.json(req.user);
});

The cors() call with no arguments sets Access-Control-Allow-Origin: * on every response. If your frontend then adds credentials: true to fetch calls, modern browsers will block the request and throw a CORS error. At that point developers often "fix" it like this:

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

Browsers block this combination too (you cannot use wildcard origin with credentials). But the intent matters: developers are being guided step by step toward maximally permissive configs, just to silence console errors.

Why AI editors keep generating this

Training data skews toward "this works" not "this is safe." Hundreds of tutorials, Stack Overflow answers, and README files show app.use(cors()) as the one-liner to get your frontend talking to your backend. That's what the model learned. When Cursor generates a backend starter, it's optimizing for immediate functionality -- wildcard CORS delivers that, so it gets generated.

The security implications don't surface until much later, if at all. Most projects never get a security review.

The actual fix

Replace the wildcard with an explicit origin allowlist. Keep the list in environment variables so staging and production configs stay separate:

// Explicit origin allowlist
const allowedOrigins = process.env.ALLOWED_ORIGINS
  ? process.env.ALLOWED_ORIGINS.split(',')
  : [];

app.use(cors({
  origin: (origin, callback) => {
    // Allow server-to-server requests (no Origin header)
    if (!origin) return callback(null, true);
    if (allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error(`CORS blocked: ${origin}`));
    }
  },
  credentials: true // safe -- origin is explicitly verified before this applies
}));

Your .env:

ALLOWED_ORIGINS=https://yourdomain.com,https://www.yourdomain.com

If you're not using the cors library:

// Manual headers -- explicit and auditable
app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  if (req.method === 'OPTIONS') return res.sendStatus(204);
  next();
});

The critical difference: you're echoing back the verified origin, not broadcasting a wildcard. Every CORS request gets an explicit answer.

One more thing -- add this to your semgrep config to catch wildcard CORS before it reaches code review:

rules:
  - id: cors-wildcard
    patterns:
      - pattern: cors({ ..., origin: '*', ... })
      - pattern: cors()
    message: Wildcard CORS detected -- replace with explicit allowlist
    severity: WARNING
    languages: [javascript, typescript]

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep will catch most wildcard CORS configs in seconds. The important thing is catching it early, whatever tool you use.

Why Cursor Keeps Hardcoding Your API Keys (And How to Stop It)

Charles Kern — Fri, 10 Apr 2026 10:46:58 +0000

TL;DR

AI assistants trained on public repos reproduce hardcoded secrets because that's what they learned
A pushed API key is effectively public even after deletion -- git history doesn't forget
Add gitleaks as a pre-commit hook today -- five minutes, blocks the problem at the source

I've been doing code reviews for teams that have fully switched to AI-assisted workflows. Cursor, Copilot, Claude Code -- all of them. And there's one pattern I keep seeing that doesn't get enough attention: hardcoded credentials.

Not occasionally. Consistently. In nearly every AI-generated file that touches external services, the first draft drops a raw API key directly into the code. Sometimes it's in a comment. Sometimes it's a constant. Once I found it hardcoded into a URL string inside a fetch() call.

This isn't a bug in the AI. It's working as designed. The models were trained on public code, and public code is full of this. StackOverflow answers from 2015, tutorial repos, quick prototypes that never got cleaned up. The model learned "here's how you call this API" from examples that had the key right there in the source.

The Vulnerable Pattern

// CWE-798: Use of Hard-coded Credentials
const stripe = require('stripe');
const client = stripe('sk_live_4eC39HqLyjWDarjtT1zdp7dc'); // live key, hardcoded

async function chargeCustomer(amount, customerId) {
  return await client.charges.create({ amount, currency: 'usd', customer: customerId });
}

The sk_live_ prefix marks it as a production Stripe key. I've seen this exact shape in multiple codebases this month. The AI fills it in because that's what completions in its training data looked like.

Why This Keeps Happening

Autocomplete makes it worse. When you type const stripe = stripe(, the model offers the most statistically likely completion. If the training data had keys in that position, it suggests a key-shaped value. The model has no concept of "this value is sensitive -- it should come from an environment variable."

The commit history problem compounds it. Even if you catch it and remove the key in the next commit, it's still in git history. A git log -p surfaces it. So does any scanner that checks commit history rather than just the current HEAD. Rotation is mandatory once a secret has been pushed.

The Fix

Two layers: prevention and detection.

Prevention -- environment variables with a startup assertion:

const stripe = require('stripe');

if (!process.env.STRIPE_SECRET_KEY) {
  throw new Error('STRIPE_SECRET_KEY is not set');
}

const client = stripe(process.env.STRIPE_SECRET_KEY);

The assertion matters. Without it, an unconfigured environment silently ships with an empty string rather than failing loudly.

Detection -- gitleaks pre-commit hook:

# Install gitleaks
brew install gitleaks  # macOS, or: go install github.com/gitleaks/gitleaks/v8@latest

# Add to .git/hooks/pre-commit
echo '#!/bin/sh
gitleaks protect --staged -v' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

Runs on staged changes only -- fast, under a second. If it finds a secret pattern, the commit is blocked before it lands.

If you've already pushed a secret:

Rotate the key immediately -- assume it's compromised
Use BFG Repo Cleaner to purge from history (faster than git filter-branch)
Force-push with --force-with-lease, coordinate with your team
Check your API provider's access logs for unauthorized usage

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

Why Cursor Generates Wildcard CORS in Every Express App

Charles Kern — Thu, 09 Apr 2026 18:18:51 +0000

TL;DR

Cursor almost always outputs cors() or cors({ origin: '*' }) with no origin restriction
Combined with credentials: true, wildcard CORS lets any site make authenticated requests to your API
Fix: set origin to an explicit domain via env variable, never '*'

Last month I spun up a side project with Cursor. Scaffolded the whole Express backend in about twenty minutes. The AI got the routes right, added input validation, even used parameterized queries for the DB calls.

Then I ran a security scan before pushing to prod. First finding: CORS, flagged as high severity. I hadn't thought about it. Cursor had generated app.use(cors()) with no arguments -- which defaults to allowing every origin on the planet.

I went back through five other projects from the past year. Same pattern every time. Not always cors() bare -- sometimes cors({ origin: '*' }) explicitly. But always a wildcard.

The Vulnerable Pattern (CWE-942)

What Cursor typically generates:

const cors = require('cors');

// Pattern 1 -- no arguments, wildcard by default
app.use(cors());

// Pattern 2 -- explicit wildcard
app.use(cors({ origin: '*' }));

Either way: any domain can make cross-origin requests to your API. That is CWE-942 -- Permissive Cross-domain Policy with Untrusted Domains.

The real danger kicks in when you also set credentials: true:

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

Browsers block this combination per the spec. But developers discover the block, search Stack Overflow, and "fix" it by swapping to a specific origin -- except by then the AI has scaffolded dozens of routes with inconsistent CORS handling.

Even without credentials, wildcard CORS on an internal API exposes your endpoint structure, response shapes, and error messages to any site that wants to probe it.

Why AI Keeps Generating This

CORS blocks you immediately and visibly. You see the red error in the browser console, Google it, and the first twenty Stack Overflow answers say app.use(cors()). Tutorial repos -- the training data -- always use the wildcard because it makes the demo work.

The AI has seen thousands of these tutorials. When you say "set up an Express server", it reaches for the pattern that appeared most often in working code. Wildcard CORS is the one that never fails to compile, never throws an error, never blocks development.

Security intent is invisible to the model. The code is syntactically valid. The tests pass. The demo runs. The vulnerability ships.

The Fix

For a single allowed origin:

app.use(cors({
  origin: process.env.ALLOWED_ORIGIN || 'https://yourapp.com',
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

For multiple origins (staging plus prod):

const allowedOrigins = (process.env.ALLOWED_ORIGINS || '').split(',');

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

Set ALLOWED_ORIGINS=https://yourapp.com,https://staging.yourapp.com in your env file. No wildcards, no guessing.

For local development without polluting prod values:

const ALLOWED_ORIGINS = process.env.NODE_ENV === 'development'
  ? ['http://localhost:3000', 'http://localhost:5173']
  : (process.env.ALLOWED_ORIGINS || '').split(',');

This way you never write origin: '*' even in dev.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

Why Cursor Keeps Writing Wildcard CORS Into Your Express API

Charles Kern — Wed, 08 Apr 2026 12:47:03 +0000

TL;DR

Cursor consistently generates cors() with no config -- equivalent to origin: '*'
When devs "fix" the credentials error, they often land on origin: true which is worse
Replace with an explicit origin allowlist -- 10 minutes, prevents any site from making credentialed requests to your API

I've been auditing side projects lately. Mostly Node/Express backends, mostly built with Cursor or Claude Code. One pattern shows up without fail: the CORS setup.

Here's what nearly every AI-generated Express app looks like at the top of the entry file:

const cors = require('cors');
app.use(cors());

The AI is not wrong to add CORS. Without it, browsers block cross-origin requests and the frontend breaks immediately. So the AI adds it. The version that works instantly. The version that also lets any website on the internet make requests to your API.

The vulnerable pattern (CWE-942)

// What Cursor generates by default
app.use(cors()); // equivalent to { origin: '*' }

// Or the explicit version
app.use(cors({ origin: '*', credentials: true }));

That second variant is rejected by browsers -- the Fetch spec does not allow * with credentials. So the developer sees the console error, googles it, and lands here:

// "Fixed" after seeing browser console error
app.use(cors({ origin: true, credentials: true }));

origin: true tells the CORS middleware to echo back whatever Origin header the request sends. Combined with credentials: true, any website can make authenticated requests to your API -- with cookies, Authorization headers, session tokens -- and read the response. That's the actual exploit.

Why the AI keeps doing this

Training data for AI editors is saturated with quick-start tutorials, Stack Overflow answers, and "get it working" repos. These all prioritize solving the immediate problem -- the browser blocking cross-origin requests -- not the security consequences.

cors() with no arguments is the fastest path to a working frontend. The AI has learned that this is what developers want. It's not wrong about that. It's just missing the follow-up step that no tutorial bothers to cover.

The fix

Replace the catch-all with an explicit allowlist:

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) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true
}));

The !origin check handles server-to-server requests and curl (which do not send an Origin header). Everything else gets validated against the list.

For multi-tenant apps or dynamic subdomains, use a pattern:

const originPattern = /^https:\/\/([\w-]+\.)?yourapp\.com$/;
origin: (origin, callback) => {
  if (!origin || originPattern.test(origin)) callback(null, true);
  else callback(new Error('Not allowed by CORS'));
}

Checking if you're already exposed

curl -H "Origin: https://evil.com" \
  -H "Access-Control-Request-Method: GET" \
  -X OPTIONS https://yourapi.com/api/users -i | grep -i "access-control"

If you see Access-Control-Allow-Origin: https://evil.com in the response -- and especially if you also see Access-Control-Allow-Credentials: true -- fix this before the next deploy.

Why Cursor Keeps Setting CORS to * (And How to Fix It)

Charles Kern — Tue, 07 Apr 2026 18:14:01 +0000

TL;DR

Wildcard CORS (Access-Control-Allow-Origin: *) shows up in the majority of AI-generated Express backends
Cursor defaults to it because most training-data CORS examples skip origin whitelisting entirely
Fix: replace origin: '*' with a runtime allowlist function -- five minutes, zero extra dependencies

I was reviewing a side project for a friend last week. Express backend, generated almost entirely with Cursor. Clean TypeScript, solid test coverage, auth working correctly. One thing stood out immediately.

Every route was open to every domain on the internet.

Not because auth was missing. The JWT middleware was fine. But at the top of server.ts:

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

This line shows up in probably eight out of ten AI-generated Express backends I've looked at. It's not a Cursor failure specifically. It's a training data problem. The StackOverflow answers that taught CORS to a generation of Node developers all used origin: '*' in their examples. They were written to solve "make the browser request work" -- not "make it work securely." LLMs absorbed that pattern.

The Vulnerable Code (CWE-346)

Here's what you get when you ask Cursor to "add CORS to my Express API":

import cors from 'cors';

// CWE-346: Origin Validation Error
app.use(cors({
  origin: '*',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true
}));

That last line is where it gets interesting. origin: '*' combined with credentials: true is rejected by most browsers -- so the developer hits a CORS error and asks their AI editor to fix it. The fix often involves setting origin to a specific string... which the AI sometimes still writes as '*', or suggests allowedHeaders: '*' as a workaround.

Even without credentials, wildcard CORS on an authenticated API means any website can make requests to your API from inside a victim's browser and read the responses. If the user is logged in, their session token flows with the request. It's not a full auth bypass, but it's a real attack surface that costs nothing to close.

Why This Pattern Persists

Three things keep it alive.

CORS errors are painful. Developers want them gone fast. "Add CORS to my Express server" is one of the most common backend setup prompts. Wildcard CORS works -- the request succeeds, no error, no warning. The developer moves on. And the attack isn't visible. No stack trace, no monitoring alert, no test failure. It just sits there until someone looks for it.

The Fix

Replace the static string with a validator function:

const ALLOWED_ORIGINS = [
  'https://yourapp.com',
  'https://www.yourapp.com',
  process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : null,
].filter(Boolean) as string[];

app.use(
  cors({
    origin: (origin, callback) => {
      if (!origin) return callback(null, true);
      if (ALLOWED_ORIGINS.includes(origin)) return callback(null, true);
      callback(new Error(`CORS blocked: ${origin}`));
    },
    credentials: true,
    methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
    allowedHeaders: ['Content-Type', 'Authorization'],
  })
);

Two things worth noting: the !origin case passes through intentionally -- server-to-server requests and CLI tools don't send an Origin header, and that's fine. Only browser cross-origin requests need the check. And credentials: true is safe here because you've replaced '*' with an actual validator.

Add one integration test:

it('blocks requests from unauthorized origins', async () => {
  const res = await request(app)
    .get('/api/user/me')
    .set('Origin', 'https://malicious.example.com');
  expect(res.headers['access-control-allow-origin']).toBeUndefined();
});

Put that in CI. It'll catch the next time someone asks an AI editor to "simplify the CORS config."

The same applies outside Express. Next.js (cors in next.config.js), FastAPI (CORSMiddleware with allow_origins), Django (CORS_ALLOWED_ORIGINS), Rails (rack-cors with origins). Every framework has this setting. Every AI editor defaults to permissive.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags these patterns before I move on. That said, even a basic pre-commit hook with semgrep and gitleaks will catch most of what's in this post. The important thing is catching it early, whatever tool you use.