Forem: Charles Kern

IDOR in AI-Generated APIs: What Cursor Won't Check for You

Charles Kern — Tue, 21 Apr 2026 21:39:39 +0000

TL;DR

AI editors generate routes that fetch resources by ID with no ownership check -- classic IDOR (CWE-639)
The pattern is everywhere in vibe-coded apps: any authenticated user can read any other user's data
One extra condition in the DB query fixes it -- the problem is AI doesn't add it unless you ask

I reviewed a side project last month. Node/Express backend, Cursor-generated, clean structure, well-commented. The developer was proud of their auth setup -- JWT tokens, bcrypt passwords, protected routes. Proper stuff.

Then I hit /api/orders/1. Logged in as user 847, I got back user 1's order. All of it. Name, address, items, total. Switched to /api/orders/2. Same result. The API was authenticated -- you needed a valid JWT to reach it. But it didn't care whose JWT you had.

This is IDOR: Insecure Direct Object Reference. OWASP ranks it #1 in the API Security Top 10. And AI editors reproduce it on every resource endpoint they generate.

The Vulnerable Pattern

Here's what Cursor outputs when you prompt "an endpoint to fetch a user's order":

// CWE-639: Authorization Bypass Through User-Controlled Key
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (!order) return res.status(404).json({ error: 'Not found' });
  res.json(order);
});

Authentication check: yes. Ownership check: no.

User 42 can hit /api/orders/99 and read user 99's full order. The only defense is knowing the right ID -- and order IDs are usually sequential integers or guessable UUIDs.

The AI isn't being careless. It completed the stated task: fetch an order by ID, require auth. The ownership check is implicit domain knowledge that didn't make it into the prompt.

Why This Keeps Happening

LLMs train on GitHub and Stack Overflow. The examples there show authentication patterns -- middleware, JWT verification, session checks. Ownership checks are rarer in tutorials because they're application-specific: the code needs to know your data model and your business rule ("a user can only access their own order").

AI doesn't know your data model unless you tell it. Most prompts don't include "and make sure the requesting user owns this resource." So the AI skips it -- not out of negligence, but because the constraint was never in the prompt.

The result: correctly authenticated, completely unauthorized.

The Fix

One extra condition in the DB query:

app.get('/api/orders/:id', authenticate, async (req, res) => {
  // Query with userId -- DB-level ownership check
  const order = await Order.findOne({
    _id: req.params.id,
    userId: req.user.id
  });
  if (!order) return res.status(404).json({ error: 'Not found' });
  res.json(order);
});

This is better than a separate if-check for two reasons. First, no information leakage -- returning 404 instead of 403 means the caller can't confirm whether ID 99 exists and belongs to someone else. Second, ownership is enforced at the query level, so there's no way to forget to check after the fetch.

Audit Your Existing Routes

A quick grep surfaces the candidates:

grep -rn "req.params" src/ | grep "findById\|findOne"

Any hit that doesn't include userId or req.user in the same query is a likely IDOR. Review each one manually.

For Express specifically: check every route using req.params.id, req.params.postId, req.params.orderId, and similar. If the query uses only the ID param and not the user ID, that endpoint probably has this bug. Check nested resources too -- /api/posts/:postId/comments/:commentId is two levels of ownership to verify.

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 MD5 Password Hashes in 2026

Charles Kern — Mon, 20 Apr 2026 17:19:48 +0000

TL;DR

AI editors surface MD5 hashing from training data dominated by 2008-2014 tutorials
MD5 hashes crack in milliseconds on modern GPUs -- any breach becomes full password exposure
Fix: one import swap to bcrypt (Python) or argon2id (Node) -- no architecture changes needed

I was reviewing a side project a friend built with Cursor. Flask backend, JWT auth, clean structure. It looked solid. Then I got to the password module.

hashlib.md5(password.encode()).hexdigest()

MD5. In 2026. About to go live.

He hadn't written it -- Cursor had. He'd accepted it because it ran, the tests passed, and the login flow worked. Nothing flagged a problem. Why would it? The code is syntactically correct. It's just cryptographically broken.

The Vulnerable Pattern (CWE-328)

Here's the exact output from Cursor on a basic auth route:

import hashlib

def hash_password(password: str) -> str:
    return hashlib.md5(password.encode()).hexdigest()  # CWE-328

def verify_password(password: str, stored_hash: str) -> bool:
    return hash_password(password) == stored_hash

CWE-328: use of a weak cryptographic hash for passwords. MD5 is a checksum algorithm designed to be fast. That speed is the problem. A modern GPU computes 10 billion MD5 hashes per second. A 6-character password cracks in milliseconds. A full user database dump becomes a near-complete plaintext list within hours.

Why AI Keeps Writing This

MD5 password hashing was the standard internet recommendation from roughly 2008 to 2014. Every PHP walkthrough, every "build a login system" tutorial from that era used it. StackOverflow answers recommending md5() accumulated thousands of upvotes before the security community caught up.

LLMs train on that corpus. The pattern is embedded. "Hash a password in Python" statistically surfaces MD5 because MD5 dominated the training data. The model isn't being careless -- it's doing exactly what next-token prediction does. The problem is the training data is old and the internet doesn't auto-update bad tutorials when better practices emerge.

SHA1 has the same issue. SHA256 is less bad but still wrong here -- it's too fast for password storage.

The Fix

Replace MD5 with bcrypt. It's slow by design -- the work factor is the security property.

import bcrypt

def hash_password(password: str) -> bytes:
    return bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt(rounds=12))

def verify_password(password: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(password.encode('utf-8'), stored_hash)

rounds=12 is the current recommended baseline. Cost-12 takes ~250ms to hash -- imperceptible to a user, catastrophic for an attacker running a brute-force. The cost factor is stored in the hash itself, so increasing it later is backward compatible.

For Node.js, argon2id is OWASP's current top recommendation:

const argon2 = require('argon2');

const hash = await argon2.hash(password, { type: argon2.argon2id });
const valid = await argon2.verify(hash, password);

Both are one-dependency swaps. Existing hashes need migration -- typically handled transparently on next login with a re-hash.

Do This Right Now

Grep your AI-generated code before anything ships:

grep -r "md5\|sha1" --include="*.py" --include="*.js" .

30 seconds. Either you're clean or you find something worth fixing before it matters.

IDOR in AI-Generated APIs: What Cursor Won't Check Automatically

Charles Kern — Sun, 19 Apr 2026 15:07:28 +0000

TL;DR

AI editors add auth middleware but skip ownership checks on resource endpoints
Any authenticated user can read or modify another user's data (CWE-639)
Fix: one line comparing req.user.id against resource.ownerId before returning data

I've been reviewing vibe-coded side projects lately. Clean code, solid tests, reasonable error handling. Then I check the API routes.

Every endpoint hits the database correctly. None of them verify whether the authenticated user actually owns the resource they're requesting. You can fetch any user's data with a valid JWT and the right resource ID. The right resource ID you can guess, enumerate, or pull from a list endpoint that leaks IDs.

This is IDOR -- Insecure Direct Object Reference (CWE-639). It sits at the top of OWASP's Broken Access Control category, the most common vulnerability class in web apps. AI code generators reproduce it constantly.

The Code AI Writes

Ask Cursor or Claude Code to build a "get user profile" endpoint:

// GET /api/users/:id  -- what Cursor generates
app.get('/api/users/:id', authenticate, async (req, res) => {
  try {
    const user = await User.findById(req.params.id);
    if (!user) return res.status(404).json({ error: 'Not found' });
    res.json(user);
  } catch (err) {
    res.status(500).json({ error: 'Server error' });
  }
});

The authenticate middleware is there. JWT validation runs. The route looks protected. But any user with a valid token can request any other user's profile by guessing or iterating IDs. MongoDB ObjectIDs are not secret. Integer IDs definitely aren't.

Same pattern on update and delete routes. The AI generates CRUD logic correctly every time. It skips the ownership check every time.

Why This Keeps Happening

AI models train on tutorials and Stack Overflow answers. Those sources teach authentication (is this user logged in?) but rarely show resource-level authorization (does this user own this specific record?).

The auth middleware satisfies the "is this endpoint protected" pattern the model recognizes. The ownership check requires understanding the relationship between the authenticated user's ID and the record being fetched. That relationship is business logic, implicit in the data model, not spelled out in any prompt. The model doesn't infer it.

Every route gets the visible security feature. Every route skips the invisible one.

The Fix

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

    // This is the line AI-generated code always skips
    if (user._id.toString() !== req.user.id) {
      return res.status(403).json({ error: 'Forbidden' });
    }

    res.json(user);
  } catch (err) {
    res.status(500).json({ error: 'Server error' });
  }
});

One comparison. One early return. That's the entire fix.

For admin routes that need cross-user access, gate it explicitly:

if (user._id.toString() !== req.user.id && req.user.role !== 'admin') {
  return res.status(403).json({ error: 'Forbidden' });
}

To audit an existing codebase fast, grep for route params without a corresponding user ID check:

# Flags routes with URL params that may be missing ownership checks
grep -rn "req.params\." src/routes/ | grep -v "req.user"

Not exhaustive, but it surfaces the obvious misses in under ten seconds.

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 a custom IDOR rule will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

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.

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.

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]

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.

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