DEV Community: Charles Kern

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.

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.

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.

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.