DEV Community: Charles Kern

IDOR in AI-Generated APIs: The Ownership Check Cursor Always Skips

Charles Kern — Sat, 13 Jun 2026 14:34:19 +0000

TL;DR

AI tools generate authenticated routes but routinely skip ownership validation -- any logged-in user can access any resource by ID
This is CWE-639 (IDOR / Broken Access Control) and it's the most common bug class I find in Cursor-generated APIs
One check after every findById call fixes the entire pattern

I reviewed a friend's side project last month. Solid app -- JWT auth, protected routes, refresh token rotation. Then I ran a quick test: logged in as User A, grabbed a document ID from the URL, opened a private tab as User B, and requested the same endpoint.

User A's data came back clean.

He'd built the whole backend in Cursor. The AI had done a genuinely good job with authentication -- middleware, token validation, all wired up correctly. But every single resource endpoint had the same gap: it checked whether you were logged in. It never checked whether the resource belonged to you.

That's CWE-639. Authorization Bypass Through User-Controlled Key. OWASP Top 10, A01: Broken Access Control. And AI code generators reproduce it at scale.

The Vulnerable Pattern

Here's what Cursor generates for a document endpoint:

// CWE-639: authenticated but no ownership check
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await Document.findById(req.params.id);
  if (!doc) return res.status(404).json({ error: 'Not found' });
  res.json(doc);
});

Authentication passes. The route looks protected. But swap :id for any valid document ID in the database and you get the data -- regardless of who owns it. Change the number. Get the record. That's IDOR.

The same pattern shows up in PUT and DELETE routes. Cursor wires up authenticate correctly every time. It skips the one line that makes the route actually private.

I've seen this pattern in payment record endpoints, private message threads, medical note APIs. The auth middleware is there. The access control is not.

Why This Keeps Happening

The reason is boring. AI models train on tutorials, StackOverflow answers, and open-source repos. Most of that code is written to teach how authentication works -- JWT validation, session middleware, token refresh. It demonstrates the concept correctly.

What tutorial code almost never models: the ownership check after the fetch. That's assumed to be obvious. It's left as an exercise. The post is about JWTs, not about who owns the document.

The model learned the template. It didn't learn the gap.

The Fix

One check. After every resource fetch:

// Fixed: ownership validated after fetch
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await Document.findById(req.params.id);
  if (!doc || doc.userId.toString() !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(doc);
});

Two notes on this:

Return 403, not 404. Returning 404 when "the document exists but isn't yours" leaks less about what IDs exist. Some teams prefer it. Either way, the ownership check is what matters.

For larger codebases, a policy layer (CASL, Casbin, or a simple assertOwnership(doc, req.user) helper) is cleaner than repeating this inline everywhere. But even the raw version above eliminates the bug class entirely.

A quick semgrep rule or grep for findById without an ownership check in the same function scope will surface every unprotected endpoint in a codebase. Takes about 15 seconds to run.

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 semgrep rule targeting findById without ownership assertions will catch most of what's in this post. The important thing is catching it before it ships, whatever tool you use.

Why Ranking #1 on Google Doesn't Mean AI Cites You

Charles Kern — Sat, 13 Jun 2026 14:32:41 +0000

A marketing director I talked to recently had a problem she couldn't explain. Her company ranked on page one for 14 of their top 15 target keywords. The SEO agency was sending monthly reports full of green checkmarks. Traffic was stable.

Then someone on her team typed their category into ChatGPT and asked for vendor recommendations.

Her company wasn't mentioned once. Not in the top suggestions. Not as an alternative. Not anywhere.

She's not alone. This is the defining blind spot in modern marketing right now, and the companies that understand what's actually happening are going to own AI search before their competitors notice the gap.

Google Ranks Pages. AI Engines Recognize Entities.

Here's what most people get wrong: Google and AI search engines are not different versions of the same system. They're built on completely different trust models, and optimizing for one does almost nothing for the other.

Google ranks pages. It crawls your content, evaluates backlinks, scores your authority signals, and surfaces the page most likely to satisfy a query. The fundamental unit is the webpage.

AI engines like ChatGPT, Perplexity, and Claude don't rank pages. They recognize entities. When someone asks "what's the best project management tool for remote teams," the LLM draws on patterns from training data — which brands have been consistently mentioned in trusted publications, who gets cited by credible sources, how coherently a company's expertise is represented across the web. The fundamental unit is the brand as an entity.

You can have a technically perfect website, great backlinks, and first-page rankings for every target keyword — and still be a complete ghost to AI search if your entity footprint doesn't exist.

The First Thing to Check Isn't Your Content

A surprising number of companies are unknowingly blocking AI crawlers. This often happens after security audits where someone adds broad disallow rules, or from legacy configurations that predate the AI search era. Open your robots.txt and look for entries like:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

If those exist, you've locked AI bots out entirely. They can't retrieve your content in any way that would lead to a citation. Fix that first. It's the quickest win with the highest potential impact.

Entity Footprint: The Concept Traditional SEO Doesn't Cover

After the technical basics, there's a deeper issue: entity footprint. This is the part that makes traditional SEO practitioners uncomfortable because it doesn't fit the keyword-and-backlink model.

AI engines learn about brands from the sources that shaped their training data. Wikipedia pages. Wikidata entries. Consistent presence on G2 or Capterra. Mentions in industry publications. Coverage from analysts or journalists in your space. Forum discussions where real users recommend specific products and explain why.

A company that has only ever been written about by itself — its own blog, its own press releases, its own social media — has a thin entity footprint from an LLM's perspective. It exists as a URL, not as a recognized entity in the world.

This is also why Reddit keeps showing up in AI citations in ways that frustrate brand marketers. Reddit threads written by real users with specific recommendations and real reasons are exactly the kind of organic, third-party signal that AI training data treats as credible. Your carefully produced white paper might lose to a three-year-old forum thread.

Getting mentioned in three credible industry publications does more for your AI citations than 50 new blog posts. That's not comfortable news, but it's accurate.

The Technical Levers That Actually Move the Needle

FAQPage schema is the single highest-leverage technical change most sites can make for answer engine optimization. Pages with properly implemented FAQPage JSON-LD show roughly 3x higher AI citation rates compared to equivalent pages without it. The mechanism is straightforward: AI systems can extract clean, citable Q&A pairs much more reliably from structured markup than from prose. If you have a product page, a service page, or a comparison page without FAQPage schema and 5-8 quality Q&A pairs, that's the next thing to add.

Alongside schema: direct answer blocks. Every key page should open with a 40-60 word paragraph that directly and completely answers the most likely query that would bring someone to that page. Not a clever hook. Not brand voice. A direct, factual answer. AI systems are looking for extractable answers — make it easy to cite you.

The data behind why this urgently matters: Gartner projected a 25% drop in traditional search volume by 2026 as AI answers absorb more queries. SaaS, legal, healthcare, and finance are already feeling this most sharply, because people in those categories are asking AI for recommendations before they even open a search engine.

The Window Is Real and It's Closing

AI share of voice in most categories is still being established. The brand that gets recognized as the authoritative entity in their space over the next 12-18 months will be very hard to displace once citation patterns solidify. This is the equivalent of getting a strong domain authority in 2012, before the SEO arms race got expensive.

Practical checklist to start this week: unblock AI bots in robots.txt if they're blocked. Add FAQPage schema to your five most important pages. Rewrite the opening paragraph of each key page to be a direct, complete answer to the most likely query. Pitch two or three industry publications for contributed content or coverage. Get listed on the major review sites in your category. Make your brand information consistent and machine-readable everywhere it appears.

Traditional SEO is still worth doing. But it's now one game of two. And right now, most companies are only playing one of them.

I'm building a tool to help with exactly this — tracking brand mentions across AI engines, auditing what's blocking citations, and showing share of voice vs competitors in AI search. It's not live yet. If you want to be notified when it launches, follow this account.

3 Broken Auth Patterns Cursor Keeps Writing Into Your API

Charles Kern — Wed, 10 Jun 2026 13:04:25 +0000

TL;DR

AI tools write jwt.decode() instead of jwt.verify() -- zero signature validation
The middleware "works" in dev so it ships, and your API silently accepts forged tokens
Replace decode with verify, explicit algorithm allowlist, wrap in try/catch

Last month I was reviewing a side project a friend asked me to look at. Node/Express backend, JWT auth, standard stuff. First thing I checked was the auth middleware. There it was: jwt.decode(token). Not jwt.verify. Not even close.

I asked how they built it. "Cursor wrote most of it." That tracks. I've seen this exact pattern in at least six projects this past year -- all AI-assisted, all using decode instead of verify.

The scary part: jwt.decode works perfectly. Tests pass. App runs. No errors. You have no idea your API accepts any token you hand it, signed or not.

The Vulnerable Code (CWE-287)

// AI-generated auth middleware
const jwt = require('jsonwebtoken');

function authMiddleware(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token' });

  const decoded = jwt.decode(token); // CWE-287: no signature verification

  if (!decoded) return res.status(401).json({ error: 'Invalid token' });

  req.user = decoded;
  next();
}

jwt.decode strips the base64 off the JWT payload and returns it as a plain object. That's it. No signature check. No expiry check. No validation that the token was signed with your secret. You could open jwt.io, swap the user ID to an admin account, and hit every protected endpoint in the app.

Two variants I've seen from Copilot and Claude Code respectively:

// Variant 1: algorithm confusion -- accepts alg:none
const decoded = jwt.verify(token, secret, { algorithms: ['HS256', 'none'] });

// Variant 2: ignoring expiry
const decoded = jwt.verify(token, secret, { ignoreExpiration: true });

Both get generated when the developer asks the AI to "stop throwing errors on token verification." The AI fixes the immediate complaint and ships broken auth.

Why AI Keeps Doing This

The pattern comes from documentation examples. JWT library READMEs show jwt.decode as a quick preview -- "here's what a decoded token looks like" -- before getting into verification. Models trained on millions of repos see this everywhere and reproduce it, especially when the surrounding context looks like "just check if the user is logged in."

The ignoreExpiration variant comes from StackOverflow workarounds for expired tokens during local testing. The AI absorbs the fix without the context of why it was temporary.

The Fix

const jwt = require('jsonwebtoken');

function authMiddleware(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token' });

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET, {
      algorithms: ['HS256'] // explicit allowlist -- never include 'none'
    });
    req.user = decoded;
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid token' });
  }
}

Three differences from the broken version: verify not decode, explicit algorithm allowlist, and a try/catch that blocks the request on any verification failure. Secret comes from an env variable -- not hardcoded, not an empty string.

Quick check to see why the algorithm allowlist matters:

node -e "const j=require('jsonwebtoken'); console.log(j.decode('eyJhbGciOiJub25lIn0.eyJ1c2VySWQiOiIxMjMifQ.'))"

That token has alg:none. Without an explicit allowlist, some configurations will accept it.

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 MD5 for Passwords (And How to Fix It)

Charles Kern — Thu, 30 Apr 2026 17:12:11 +0000

TL;DR

AI editors frequently output MD5 or SHA-1 for password hashing -- both broken for this purpose
Root cause: training data from pre-2015 tutorials where MD5 was common practice
Fix: bcrypt (cost 12) or argon2. Pick one. Three-line swap.

I was reviewing a friend's side project last month. Node.js backend, clean architecture, React frontend. He'd built the whole thing with Cursor over a weekend. The auth flow looked right at a glance -- passwords were stored as hashes, login worked, tests passed.

Then I saw the hashing function.

import hashlib
hashed = hashlib.md5(password.encode()).hexdigest()  # CWE-328

MD5 is not a password hashing algorithm. It never was. It's a checksum function that completes in under 1 microsecond per hash. On a consumer GPU, an attacker can run 60 billion MD5 hashes per second. The entire rockyou2024 dataset -- 10 billion passwords -- cracked in under 3 minutes.

Why AI Editors Keep Generating This

It's not a model bug. It's a training data artifact.

The internet has thousands of Python and PHP tutorials from 2008-2015 that use MD5 for password storage. Stack Overflow answers with thousands of upvotes. Old framework docs. These pages rank well in search, which means they were in the training corpus.

When you type "hash user password Python", the model pattern-matches against the most common code it's seen -- and that code is frequently from a decade ago. The model has no concept of "this was common but is now a known vulnerability". It sees frequency. MD5 appears often next to "password hash" in training data, so it appears often in output.

SHA-1 shows up for the same reason. Slightly slower than MD5, equally broken for this use case.

The Vulnerable Pattern

# CWE-328: Use of Weak Hash -- AI-generated output
import hashlib

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

def verify_password(password: str, stored_hash: str) -> bool:
    return hashlib.md5(password.encode()).hexdigest() == stored_hash  # ❌

This is the exact output Cursor gives when you prompt "add password hashing to this Flask endpoint" with no other context. The JavaScript version is equally common:

// CWE-328 -- same problem
const crypto = require('crypto');
const hash = crypto.createHash('md5').update(password).digest('hex'); // ❌

The Fix

bcrypt is the safe default. Deliberately slow, well-audited, supported in every language:

import bcrypt

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

def verify_password(password: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(password.encode(), stored_hash)  # ✅

The rounds=12 work factor means each hash takes ~250ms. A GPU that cracks MD5 at 60B hashes/sec is reduced to ~1,000 bcrypt hashes/sec. The economics of brute force collapse.

For new projects, argon2 is the current OWASP recommendation:

from argon2 import PasswordHasher
ph = PasswordHasher()
hashed = ph.hash(password)         # ✅
ph.verify(hashed, password)        # ✅

Node.js:

const bcrypt = require('bcrypt');
const hash = await bcrypt.hash(password, 12);          // ✅
const match = await bcrypt.compare(password, hash);    // ✅

One migration note: if you have existing MD5 hashes in your database, you cannot re-hash them -- you don't have the plaintext. The correct path is re-hashing on next login. User logs in, verify against MD5, then immediately replace with bcrypt. Active users migrate naturally. Dormant accounts get a forced password reset.

Also -- add this to your .cursorrules: "For all password hashing, use bcrypt cost 12 or argon2. Never use MD5, SHA-1, or SHA-256 for password storage." One instruction. The model follows it every time.

AI-Generated APIs Have an IDOR Problem: 3 Patterns Cursor Misses

Charles Kern — Tue, 28 Apr 2026 06:25:40 +0000

TL;DR

AI editors add authentication middleware but skip per-resource ownership checks by default
Any logged-in user can access another user's data by guessing or incrementing an ID
Fix: scope ownership into the DB query -- one line before you ship, not after

I was reviewing a side project built almost entirely with Cursor. Clean code. Tests passing. Already deployed.

Then I spotted this:

app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await Document.findById(req.params.id);
  res.json(doc);
});

The authenticateToken middleware ran. So the route looked protected. But there was no check that req.user.id === doc.userId. Any authenticated user could read any document by guessing the ID. That's IDOR. CWE-862. And it's in almost every AI-generated API I've reviewed.

Why AI editors get this wrong

AI tools are trained on tutorials and StackOverflow answers. Tutorials teach authentication -- "add this middleware and your route is secure." They almost never teach authorization -- "now verify the authenticated user is allowed to access this specific record."

The model learns: authenticateToken = protected. It doesn't learn the follow-up. I've seen this in Cursor output, Claude Code output, and Copilot suggestions. All three get authentication right. All three miss authorization.

The three patterns to watch for

Pattern 1 -- No ownership check at all (CWE-862)

// ❌ CWE-862: Missing Authorization
app.get('/api/orders/:id', authenticateToken, async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (!order) return res.status(404).json({ error: 'Not found' });
  res.json(order);
});

// ✅ With ownership check
app.get('/api/orders/:id', authenticateToken, async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (!order) return res.status(404).json({ error: 'Not found' });
  if (order.userId.toString() !== req.user.id) return res.status(403).json({ error: 'Forbidden' });
  res.json(order);
});

Pattern 2 -- Delete endpoints are worse

// ❌ Any authenticated user can delete any record
app.delete('/api/posts/:id', authenticateToken, async (req, res) => {
  await Post.findByIdAndDelete(req.params.id);
  res.json({ success: true });
});

No check who owns the post. The AI generated working code. It's just wrong.

Pattern 3 -- Related resource fetches without scope

// ❌ Returns comments for any post, regardless of ownership
app.get('/api/posts/:id/comments', authenticateToken, async (req, res) => {
  const comments = await Comment.find({ postId: req.params.id });
  res.json(comments);
});

This one is subtle. The endpoint itself might be intentionally public. But in a private notes app? It's data exposure by default.

The better fix -- bake ownership into the query

Don't fetch first, check second. Instead, filter at the DB level:

// Ownership enforced at query time -- not application logic
const doc = await Document.findOne({
  _id: req.params.id,
  userId: req.user.id
});
if (!doc) return res.status(404).json({ error: 'Not found' });

Two advantages. First, you get 404 instead of 403 -- you don't leak whether the resource exists at all. Second, even if your application-level check has a bug, the DB query won't return the wrong user's data.

What to tell your AI editor

If you're using Cursor or Claude Code, add this to your system prompt or rules file:

After every resource fetch, check that req.user.id matches the resource's owner field. Use findOne with ownership in the query filter, not findById followed by a check. Return 404, not 403.

It works. The model follows explicit rules better than it infers them from context.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags CWE-862 patterns before I move on. That said, a pre-commit semgrep rule scanning for findById calls not followed by an ownership comparison catches most of what's in this post. Catch it early, whatever your tool.

Why Cursor Keeps Writing MD5 Password Hashes (CWE-328)

Charles Kern — Mon, 27 Apr 2026 14:28:36 +0000

TL;DR

AI editors default to MD5/SHA1 because training data is dominated by pre-2012 tutorials
MD5 cracks in hours on a consumer GPU -- this is not theoretical
Fix: bcrypt at rounds=12, or Argon2id for new projects

A few weeks ago a developer asked me to review his side project before pushing to production. Node.js backend, Cursor-built, clean architecture. The password storage looked like this:

const hash = crypto.createHash('md5').update(password).digest('hex');
await db.query('INSERT INTO users (email, password) VALUES ($1, $2)', [email, hash]);

MD5. In 2026. Not because the developer was careless -- because Cursor generated it and it worked.

I've now seen this in three separate projects over the past few weeks. Different developers, different apps, same pattern. The AI editors are consistent about it.

The Vulnerable Pattern (CWE-328)

// All three are wrong for password storage
crypto.createHash('md5').update(password).digest('hex');    // CWE-328 ❌
crypto.createHash('sha1').update(password).digest('hex');   // CWE-328 ❌
crypto.createHash('sha256').update(password).digest('hex'); // Still wrong for passwords ❌

MD5 and SHA-1 are broken for collision resistance. But even SHA-256 is the wrong tool. The problem is speed. SHA-256 can hash billions of inputs per second on a GPU. That's exactly what makes it wrong for passwords.

A leaked database of MD5-hashed passwords is cracked in hours with a wordlist and a consumer GPU. SHA-256 is even faster, so it goes even faster.

Why AI Keeps Generating This

Training data volume. There are millions of StackOverflow answers, blog posts, and GitHub gists from 2008-2019 showing MD5 and SHA-1 for password hashing. bcrypt has been the right answer since around 2012, but old content drowns it out by sheer volume.

When you ask Cursor to "implement user registration," it pattern-matches against its training distribution. The most common association for "hash a password in Node.js" includes the crypto module with MD5 -- because that association appears millions of times in training data.

The model isn't broken. It's doing what it learned. The problem is what it learned from.

The Fix

const bcrypt = require('bcrypt');

// 12 rounds is the current recommended minimum
const hash = await bcrypt.hash(password, 12); // ✅

// Verification -- never compare raw strings
const isValid = await bcrypt.compare(inputPassword, storedHash); // ✅

For new projects, Argon2id is now OWASP's top recommendation:

const argon2 = require('argon2');

const hash = await argon2.hash(password); // Argon2id by default ✅
const isValid = await argon2.verify(hash, inputPassword); // ✅

Python:

import bcrypt

hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))  # ✅
is_valid = bcrypt.checkpw(input_password.encode(), hash)  # ✅

The cost factor matters. bcrypt at rounds=12 adds ~200-300ms per login check. Fine for users. For an attacker hashing billions of guesses, that latency scales linearly into years.

One Command to Check Your Codebase Now

grep -r "createHash" . --include="*.js" --include="*.ts" --include="*.py" | grep -iE "md5|sha1"

If that returns results near any auth code, fix it before anything else ships.

3 SQL Injection Patterns Cursor Keeps Writing Into Your API

Charles Kern — Sun, 26 Apr 2026 12:57:45 +0000

TL;DR

AI editors generate SQL queries with template literals -- directly injectable, CWE-89
This pattern shows up in ~40% of vibe-coded backends with any database layer
Fix: parameterized queries everywhere, no exceptions

I was reviewing a friend's side project last week. Node.js API, React frontend, Postgres. Clean architecture, good folder structure. Then I looked at the query layer.

Every single database call was built with template literals. Not one parameterized query in the whole codebase. I ran sqlmap against the search endpoint in about 30 seconds and had a full database dump.

This wasn't my friend's oversight. Cursor wrote those queries. And it keeps writing them that way.

Pattern 1: The Classic Template Literal

You ask Cursor for a search endpoint. It gives you this:

// CWE-89 -- SQL injection via template literal
app.get('/api/users', async (req, res) => {
  const { name } = req.query;
  const users = await db.query(`SELECT * FROM users WHERE name = '${name}'`);
  res.json(users);
});

name goes straight into the query string. A request with name='; DROP TABLE users; -- does exactly what you think it does. No parsing, no escaping, just execution.

The fix is one line:

const users = await db.query('SELECT * FROM users WHERE name = $1', [name]);

The database driver handles escaping. The query structure is fixed at parse time. User input cannot change what the query does.

Pattern 2: String Concatenation

Older pattern, but Cursor still generates it when you ask for something simple like "fetch order by ID":

// CWE-89 via string concatenation
const order = await db.query(
  "SELECT * FROM orders WHERE id = " + req.params.id
);

req.params.id is a string. It's never validated. If it contains SQL, it runs.

// Parameterized
const order = await db.query(
  'SELECT * FROM orders WHERE id = $1',
  [req.params.id]
);

Even for numeric-looking IDs, always parameterize. Add type validation on top if you want -- but parameterize first.

Pattern 3: ORM Escape Hatch

This one's the sneakiest. Developers assume using Sequelize or Prisma makes them safe. It doesn't, when the AI reaches for the raw query escape hatch:

// Looks like ORM, but it's not safe
const results = await User.findAll({
  where: db.literal(`name = '${req.query.search}'`)
});

db.literal() tells Sequelize to pass that string directly to the database unescaped. You're back to raw string interpolation, wrapped in an ORM call that makes it look safe.

// Actual safe ORM usage
const results = await User.findAll({
  where: { name: req.query.search }
});

If you need complex conditions, Sequelize has Op.like, Op.and, Op.or. Use those. Never db.literal() with user-controlled input.

Why This Keeps Happening

Template literals and string concatenation dominate documentation, tutorials, and StackOverflow answers -- especially the older ones that LLMs were trained on. The unsafe pattern is readable. It makes the SQL structure obvious. It's what most examples show.

LLMs pattern-match to what appeared most in training data. Parameterized queries show up less frequently there, because tutorial authors optimize for clarity, not security. The "security hardening" section at the bottom of a tutorial is what fewer people read, click on, and link to -- so it's underrepresented in training data.

The model isn't choosing to generate insecure code. It's completing a token sequence that matches what it learned.

Catching It Before It Ships

Two grep commands that catch most of what Cursor generates:

# Template literal SQL
grep -rn 'query.*\`.*\${'  ./src

# String concatenation in queries
grep -rn 'query.*+.*req\.' ./src

Run these in pre-commit. They won't catch everything, but they catch the most common AI-generated patterns.

Prototype Pollution: What Cursor's Object Merge Code Misses

Charles Kern — Sat, 25 Apr 2026 20:24:02 +0000

TL;DR

Cursor and Claude Code default to for...in object merge -- a CWE-1321 prototype pollution vector
Root cause: AI training data skews toward pre-2019 StackOverflow answers that predate Object.hasOwn()
One-line fix closes it entirely -- AI just never adds it unless you ask

Last week I was reviewing a side project a friend asked me to look over. Node backend, built almost entirely in Cursor. Clean structure, good variable names, even some inline comments. Genuinely readable. Then I hit the utility functions.

One was a deep merge helper. The kind every backend has -- takes two objects, recursively merges keys. AI writes these instantly. The problem is what it doesn't write.

Here's what Cursor generated, verbatim:

// CWE-1321 -- prototype pollution via for...in merge
function deepMerge(target, source) {
  for (const key in source) {
    if (source[key] && typeof source[key] === 'object') {
      target[key] = deepMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

for...in iterates inherited properties. If an attacker controls the source object -- via a JSON body, a query param, a config file -- they can inject __proto__ as a key and pollute Object.prototype for the entire Node process.

Concretely:

deepMerge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));
console.log({}.isAdmin); // true -- every object in the process is now an admin

Admin endpoints become public. Audit logs get skipped. Auth middleware that checks req.user.isAdmin becomes worthless.

Why AI Keeps Writing This

The for...in merge is the canonical StackOverflow answer from roughly 2013 to 2019. Thousands of upvoted posts, hundreds of blog tutorials, dozens of npm packages that shipped this pattern and never updated. LLMs trained on that corpus reproduce it faithfully.

Object.hasOwn() and explicit __proto__ guards are more recent conventions. They exist in the training data, but mostly in security-focused articles -- not in the general "how to deep merge objects in JS" posts that dominate the corpus. The model defaults to the most statistically common answer. That answer is the insecure one.

This isn't specific to Cursor. Claude Code does it. Copilot does it. Any model trained on pre-2020 JavaScript tutorials will reproduce this pattern. The only thing that changes it is context -- if your prompt or surrounding code signals a security focus, the model sometimes adds the guard. Most prompts don't.

The Fix

Two options. Pick one.

Option 1 -- Guard with Object.hasOwn() (minimal change):

function deepMerge(target, source) {
  for (const key in source) {
    if (!Object.hasOwn(source, key)) continue; // blocks __proto__ + inherited keys
    if (source[key] && typeof source[key] === 'object') {
      target[key] = deepMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

Option 2 -- Switch to Object.keys() (only own enumerable props, no inherited iteration):

function deepMerge(target, source) {
  Object.keys(source).forEach(key => {
    if (source[key] && typeof source[key] === 'object') {
      target[key] = deepMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  });
  return target;
}

Option 1 is the minimal change if you're not refactoring. Option 2 is cleaner and removes the inherited iteration entirely.

If you're parsing untrusted JSON before merging, add a shape check:

function isSafeObject(obj) {
  return !('__proto__' in obj) && !('constructor' in obj) && !('prototype' in obj);
}

Reject payloads that fail this check before they reach your merge function.

One More Thing

This pattern doesn't just live in utility files. It shows up in config loaders, settings mergers, patch endpoints, and anywhere an AI generates "merge user input with defaults." Search your repo for for (const key in and audit every hit. The vulnerability surface is usually wider than one file.

Cursor Keeps Writing IDOR Into Your APIs. Here's the Fix.

Charles Kern — Fri, 24 Apr 2026 05:34:44 +0000

TL;DR

AI editors generate authenticated endpoints with no ownership verification
Any valid JWT holder can read any other user's data by guessing an ID
Fix: scope the query to the requesting user, or check ownership immediately after fetch

I've been reviewing side-project codebases for the past few weeks. The stack varies -- Express, FastAPI, Rails, doesn't matter. The bug is always the same.

Someone asked Cursor or Claude Code to add an API endpoint to fetch user data. The AI wrote working code. Correct query, correct response shape, even a 404 handler. What it skipped was the line that checks whether the person asking actually owns the record they're asking for.

This is IDOR -- Insecure Direct Object Reference. CWE-862. OWASP Top 10. The reason it keeps showing up in AI-generated code isn't random.

The Vulnerable Endpoint

Here's the pattern:

// CWE-862 -- Missing Authorization
app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await Document.findById(req.params.id);
  if (!doc) return res.status(404).json({ error: 'Not found' });
  res.json(doc);
});

The middleware runs. The user is authenticated. But the document goes back to whoever asked, regardless of whether they own it. Authenticated but unauthorized. That's the gap.

Exploiting it is trivial. Open the network tab, grab any document ID from your own responses, increment it by 1, send the same request. If the server responds with another user's document, you've found the bug.

Why AI Gets This Wrong

The training data problem is straightforward. Tutorials that demonstrate "how to build a REST API" don't include authorization logic. They prove the concept. The code gets the data and returns it. That's enough to teach the pattern.

When you ask the AI to "add an endpoint that returns a document by ID", it does exactly that. It doesn't anticipate that an authenticated attacker will probe IDs they don't own. The happy path works. The adversarial path is invisible to it.

The Fix

Two lines added immediately after the fetch:

// Fixed -- ownership check before response
app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await Document.findById(req.params.id);
  if (!doc) return res.status(404).json({ error: 'Not found' });
  if (doc.userId.toString() !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(doc);
});

Or scope the query from the start so the check is structural:

const doc = await Document.findOne({ _id: req.params.id, userId: req.user.id });

Same fix across frameworks. Django: Document.objects.get(pk=id, user=request.user). FastAPI: inject current_user and filter by owner. Rails: current_user.documents.find(params[:id]).

The rule is simple: never return a user-scoped resource fetched by ID alone.

Where to Catch It

Audit every route that accepts an :id or ?id= parameter and returns a database record. Count the ownership checks. Any route missing one is an IDOR candidate.

A semgrep one-liner:

semgrep --config=r/owasp.idor . --include="*.js" --include="*.py"

IDOR in Cursor-Generated Code: The Auth Bug Nobody Checks For

Charles Kern — Thu, 23 Apr 2026 13:42:10 +0000

TL;DR

AI-generated CRUD endpoints routinely skip ownership checks (CWE-639)
Any authenticated user can read, modify, or delete another user's data
Fix: one ownership check before every data access, no exceptions

I've been reviewing AI-assisted codebases for a while now, and one pattern keeps showing up more than any other. Not SQL injection, not hardcoded secrets -- those get caught. The one that slips through is IDOR: Insecure Direct Object Reference.

Here's what it looks like. You ask Cursor to build a task detail endpoint. It generates this:

// ❌ CWE-639: No ownership check
app.get('/api/tasks/:id', authenticate, async (req, res) => {
  const task = await Task.findById(req.params.id);
  if (!task) return res.status(404).json({ error: 'Not found' });
  res.json(task);
});

The authenticate middleware runs. JWT is validated. The user is "authenticated." But the handler fetches whatever ID was in the URL and returns it -- no check that task.userId === req.user.id.

An attacker with a valid account can iterate IDs: /api/tasks/1, /api/tasks/2, /api/tasks/3. They pull every record in the database. The same flaw shows up on write routes:

// ❌ CWE-639: Anyone can overwrite anyone's data
app.put('/api/tasks/:id', authenticate, async (req, res) => {
  const task = await Task.findByIdAndUpdate(req.params.id, req.body, { new: true });
  res.json(task);
});

Any authenticated user can update any task. Delete any record. IDOR has been in the OWASP Top 10 for a reason.

Why AI Keeps Getting This Wrong

Most authentication examples online show JWT validation and middleware setup. The ownership check is domain-specific -- it depends on the data model -- so it rarely appears in generic tutorials or StackOverflow answers.

AI models learn those patterns. They know to add authenticate middleware. They don't consistently learn that authentication (who you are) and authorization (what you can access) are separate concerns requiring separate checks.

Authentication: are you logged in?
Authorization: is this yours?

Cursor handles the first. It skips the second.

The Fix

One ownership check per data operation:

// ✅ Verify ownership after fetching
app.get('/api/tasks/:id', authenticate, async (req, res) => {
  const task = await Task.findById(req.params.id);
  if (!task) return res.status(404).json({ error: 'Not found' });
  if (task.userId.toString() !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(task);
});

Return 403, not 404, on access denial. 404 makes the resource appear nonexistent -- useful in some threat models, confusing in most production apps.

For write operations, enforce ownership directly in the database query -- atomic, no race condition:

// ✅ Ownership enforced at query level
const task = await Task.findOneAndUpdate(
  { _id: req.params.id, userId: req.user.id },
  req.body,
  { new: true }
);
if (!task) return res.status(404).json({ error: 'Not found or forbidden' });

The pattern applies beyond tasks. Files, comments, profiles, settings -- any resource tied to a user needs an ownership check on every read, write, and delete. One check. Every time. No exceptions.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags missing ownership checks before I move on. That said, even a basic pre-commit hook with semgrep rules for CWE-639 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: What Cursor Won't Check for You

Charles Kern — Wed, 22 Apr 2026 17:59:30 +0000

TL;DR

Cursor generates authenticated API routes with no ownership verification by default
This creates IDOR (CWE-639) -- any logged-in user can read or delete any other user's data
Fix is 3 lines: check resource.userId === req.user.id before returning anything

I was reviewing a friend's side project last week. TypeScript, Prisma, built almost entirely in Cursor. Clean code, good structure, auth middleware on every route.

I asked him to pull up his /api/documents/:id endpoint.

No ownership check. User 42 could request /api/documents/1 and get user 1's private documents back with a 200. No error. No log. Just data. He had no idea -- Cursor never flagged it.

The Vulnerable Code Pattern (CWE-639)

Prompt Cursor with "create a GET endpoint to fetch a document by ID" and you'll get something like this:

// ❌ CWE-639: No ownership verification
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await prisma.document.findUnique({
    where: { id: req.params.id }
  });
  if (!doc) return res.status(404).json({ error: 'Not found' });
  res.json(doc);
});

The authenticate middleware is there. JWT is verified. But there's no check that doc.userId === req.user.id.

Any authenticated user can iterate IDs -- /api/documents/1, /api/documents/2 -- and pull every record in the database. That's a textbook IDOR (Insecure Direct Object Reference).

Why AI Keeps Writing This

AI code assistants are trained on millions of tutorials and StackOverflow answers. Most of those examples show authentication. Almost none show authorization.

Authentication answers "are you who you claim to be?" Authorization answers "are you allowed to access this specific resource?" The second check is nearly absent from tutorial code -- tutorials demonstrate concepts, not production security patterns.

Cursor, Claude Code, Copilot -- they all reproduce this gap faithfully. When you prompt for a CRUD endpoint, the model generates code that satisfies the prompt. Ownership checking isn't in the prompt, so it doesn't appear in the output.

The Fix -- 3 Lines

// ✅ Ownership check added
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await prisma.document.findUnique({
    where: { id: req.params.id }
  });
  if (!doc) return res.status(404).json({ error: 'Not found' });

  // The three lines that matter:
  if (doc.userId !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  res.json(doc);
});

A few things worth noting:

Return 403, not 404. Some teams prefer 404 to avoid leaking that the resource exists. Both are defensible -- pick one and stay consistent across your API.

Don't just filter in the query. Adding userId: req.user.id to the where clause silently returns null instead of throwing 403. It works, but it makes debugging harder and breaks explicit logging. Make intent clear.

Check before business logic runs. If anything happens between fetching and returning the resource, gate on ownership first.

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 semgrep rule watching for findUnique calls without an ownership comparison will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

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.