DEV Community: Charles Kern

Why Cursor Keeps Hashing Passwords With MD5 (And How to Fix It)

Charles Kern — Sat, 04 Jul 2026 16:07:26 +0000

TL;DR

AI editors still reach for md5/sha1 to hash passwords because that is what a decade of tutorials taught them
Fast hashes are the whole problem: they let attackers brute force leaked password databases at billions of guesses per second
Swap to bcrypt or argon2id. Two lines. Do it before you ship.

I asked Cursor to add a signup endpoint to a side project last week. Clean code, worked first try. Then I read the part where it stored the password: one line, hashlib.md5. No salt. No work factor. Just a raw MD5 digest sitting in my users table.

I have seen this enough times now that I stopped being surprised. Claude Code does it. Copilot does it. Ask any AI editor to "hash the password before saving" and there is a real chance you get MD5 or SHA-1 back.

The vulnerable code

import hashlib

# CWE-916: fast hash, no salt, no work factor
def store_password(password):
    return hashlib.md5(password.encode()).hexdigest()

Sometimes it is SHA-1 instead. Sometimes SHA-256. It does not matter. They are all built to be fast, and speed is exactly what you do not want here.

Why this keeps happening

The training data. MD5 password hashing was standard advice on StackOverflow and in PHP tutorials for the better part of a decade. Millions of examples. The models learned the pattern because the pattern was everywhere. They do not know that in 2012 LinkedIn leaked 6.5 million unsalted SHA-1 passwords and most were cracked within days. They just know that "hash a password" and "md5" show up together a lot.

The math is the real problem. A modern GPU rig computes billions of MD5 hashes per second. If your user database leaks, and databases leak, every common password falls almost instantly. No salt means identical passwords produce identical hashes, so one rainbow table cracks your whole table at once.

The fix

Use a slow hash built for passwords: bcrypt, scrypt, or argon2id. They are deliberately expensive to compute, which barely matters for a single login but wrecks an attacker running billions of guesses.

import bcrypt

# salted, slow by design, tuneable work factor
def store_password(password):
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

def verify_password(password, stored):
    return bcrypt.checkpw(password.encode(), stored)

bcrypt salts automatically, so you never manage it yourself. rounds=12 is a sane default in 2026. If you want the current best practice, argon2id via the argon2-cffi library is the OWASP-recommended choice.

Install and you are done:

pip install bcrypt

The catch: your AI editor will not flag the MD5 version. It is valid Python. It runs. It passes your tests. Nothing tells you it is wrong until the breach.

I have been running SafeWeave for exactly this. It hooks into Cursor and Claude Code as an MCP server and flags weak crypto like md5/sha1 password hashing before I move on to the next file. That said, even a basic pre-commit hook with semgrep will catch most of it. The important thing is catching it while you still have the context, whatever tool you use.

Why Cursor's CORS Fix Opens Your API to Any Website (CWE-942)

Charles Kern — Fri, 03 Jul 2026 09:28:30 +0000

TL;DR

Ask Cursor to "fix the CORS error" and you usually get a wildcard or a reflected origin
Reflected origin plus credentials means any website can act as your logged-in users
An explicit allowlist is five lines. There is no good excuse to skip it.

Last week I reviewed an Express API a friend built almost entirely with Cursor. Clean structure, decent tests, tidy commit messages. Then I opened the middleware file and found the one line that undid all of it.

The story is always the same. You wire the frontend to the backend, the browser console throws the famous red error: "blocked by CORS policy". You paste it into the AI chat. The error disappears in ten seconds. What you shipped instead is CWE-942, a permissive cross-domain policy.

The code Cursor writes

The first attempt usually looks harmless:

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

Then cookies stop working, because browsers refuse to send credentials to a wildcard origin. So you tell the AI "auth requests are failing now" and it produces the real problem:

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

That callback reflects every origin back to the browser. Combined with credentials: true, any website on the internet can make authenticated requests to your API from a visitor's browser and read the responses. Your users' session cookies do the authentication for the attacker. A malicious site just needs one of your users to have a live session.

I have also seen the manual version:

res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');

Same hole, no library needed.

Why this keeps happening

Three reasons, and none of them are the AI being stupid.

Training data is the first. Thousands of StackOverflow answers to CORS questions boil down to "allow everything, it works". Those answers were written for localhost tutorials where the wildcard genuinely does not matter. The model learned the pattern without the context.

The second reason is feedback asymmetry. A CORS error is loud. It is red, it is in your console, it blocks your demo. The vulnerability it hides is silent. Nothing in your test suite fails when your API trusts every origin. The AI is optimizing for the visible signal, and so are you.

Third: CORS is confusing enough that most developers cannot review the fix. If you do not know that credentials plus wildcard is blocked by browsers but credentials plus reflected origin is not, the dangerous version looks like the clever version.

The fix

Explicit allowlist. Five lines that matter:

const ALLOWED_ORIGINS = [
  'https://app.example.com',
  'https://staging.example.com'
];

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

Rules I follow now on every vibe-coded backend. Never reflect req.headers.origin without checking it against a list. Treat credentials: true as the dangerous flag that triggers a manual review. Keep the allowlist in config, not scattered across route files. And grep for Access-Control-Allow-Origin before every deploy. It takes four seconds.

I have been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags permissive CORS and reflected origins before I move on to the next prompt. That said, even a basic pre-commit hook with semgrep will catch most of what is in this post. The important thing is catching it early, whatever tool you use.

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

Charles Kern — Tue, 30 Jun 2026 13:41:25 +0000

TL;DR

AI coding assistants paste real-looking secrets straight into source files because that is what their training data did.
The key gets committed, pushed, and scraped from public repos within minutes.
Move secrets to environment variables and run a pre-commit secret scanner. That is the whole fix.

I was reviewing a small Flask app a friend built almost entirely with Cursor. Nice little tool. Then I opened the main module and the first line that wasn't an import was an OpenAI key sitting in plain text. A real one. Still active.

He didn't put it there. He asked the assistant to "add the OpenAI call" and it helpfully wired up the client, key and all. The key was his, pasted in during an earlier prompt, and the model just kept reusing it inline every time it touched that file.

The vulnerable code

This is roughly what was in there (CWE-798: Use of Hard-coded Credentials):

import openai

openai.api_key = "sk-proj-9aXfK2mQ8vNpL4rT7wYzB3cD5eF1gH6j"

def summarize(text):
    resp = openai.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": text}]
    )
    return resp.choices[0].message.content

It runs. Tests pass. It also leaks the moment the repo goes public, and bots scan new GitHub commits for exactly this pattern in seconds.

Why this keeps happening

The model learned from millions of tutorials and StackOverflow answers where the author dropped a literal key inline to keep the example short. That shortcut is everywhere in the training data, so the model treats inline secrets as the normal way to show working code. It has no concept of which strings are sensitive. To the model, "sk-proj-..." is just a string that makes the example complete.

The fix

Pull the secret out of source entirely:

import os
import openai

openai.api_key = os.environ["OPENAI_API_KEY"]

Put the real value in a .env file, add .env to .gitignore, and catch mistakes before they ship with a scanner:

pip install pre-commit
# .pre-commit-config.yaml with gitleaks
gitleaks detect --source . --no-banner

Then rotate the key that was already exposed, because once it touches a commit it is burned.

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

Why Cursor Keeps Installing Vulnerable npm Packages

Charles Kern — Mon, 29 Jun 2026 16:06:51 +0000

TL;DR

AI editors pin package versions frozen at their training cutoff, so the "latest" they install is often months or years out of date and ships with known CVEs.
I keep finding lodash 4.17.11 and PyYAML 3.13 in fresh AI-generated projects. Both have public advisories for prototype pollution and remote code execution.
Audit dependencies at the moment code is generated, not a week later in CI.

Last week I asked Cursor to scaffold a small Node service. It wrote clean code, set up the routes, and dropped in a package.json. I almost shipped it. Then I ran an audit out of habit and found lodash pinned at 4.17.11.

That version has a public prototype pollution advisory, CVE-2019-10744. It was patched in 4.17.12, which shipped back in July 2019. The AI handed me a dependency that had been fixable for years.

This is not a one-off. I have seen the same pattern across enough AI-generated projects that I now treat every fresh package.json and requirements.txt as guilty until audited.

The vulnerable code

Here is the dependency the AI gave me:

// package.json generated by the AI
{
  "dependencies": {
    "lodash": "4.17.11"
  }
}

lodash 4.17.11 is vulnerable to prototype pollution via defaultsDeep (CWE-1321, CVE-2019-10744). A crafted {constructor: {prototype: {...}}} payload can modify Object.prototype and quietly affect every object in your runtime.

Python is no safer:

# requirements.txt generated by the AI
PyYAML==3.13

PyYAML before 5.4 allows arbitrary code execution through full_load and FullLoader (CVE-2020-14343). If any YAML you parse comes from a user, that is a remote code execution bug sitting in your install list.

Why this keeps happening

The model has a training cutoff. When it writes a dependency list, it reaches for the version that was current inside its training window. That version felt safe at the time. It is not safe now.

The AI has no live view of the npm or PyPI advisory database. It cannot know that 4.17.11 was superseded, or that a CVE landed after its cutoff. It is confidently recommending a snapshot of the past.

It gets worse with transitive dependencies. The package you pin pulls in its own tree, and those sub-dependencies are equally frozen. One outdated top-level package can drag in a dozen vulnerable ones you never typed out.

The fix

Audit at the moment the code is generated, not a week later in CI.

For npm:

npm audit
npm audit fix

For the lodash case, bump it to the patched line:

npm install lodash@4.17.21

For Python:

pip install pip-audit
pip-audit -r requirements.txt

Then pin the patched version:

PyYAML>=5.4

The general rule: never trust a version number an AI gave you. Cross-check it against the advisory database before it reaches your lockfile. A lockfile is good, but a lockfile full of vulnerable versions just makes the vulnerability reproducible.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and runs a dependency audit across npm, pip, cargo, go, and bundler the moment code is generated, so the outdated package never reaches my lockfile. That said, even a plain npm audit and pip-audit in a pre-commit hook will catch most of what is in this post. The important thing is checking versions early, whatever tool you use.

Why Cursor Keeps Hardcoding Secrets in AI-Generated Code (CWE-798)

Charles Kern — Sun, 28 Jun 2026 08:44:59 +0000

TL;DR

AI editors hardcode API keys, tokens, and JWT secrets straight into source because their training data is full of tutorials that do exactly that.
A hardcoded secret in a public repo is compromised the moment it is pushed, not when someone finds it.
Scan for secrets before every commit and move them to environment variables. It takes 30 seconds.

I asked Cursor to wire up Stripe billing for a side project last week. It gave me working code in about ten seconds. It also gave me this:

const stripe = require('stripe')('sk_live_51Abc...realkey...xyz');
const JWT_SECRET = 'super-secret-key-change-me';

The code ran. Payments worked. And I almost committed a live Stripe key to a public GitHub repo without noticing, because everything looked fine.

This is not a Cursor problem specifically. Claude Code, Copilot, and Windsurf all do it. The pattern is everywhere in the training data, so the model reproduces it.

The vulnerable pattern (CWE-798)

Here is the kind of thing AI editors generate constantly:

// Hardcoded secret - CWE-798
const stripe = require('stripe')('sk_live_51Abc...xyz');
const JWT_SECRET = 'super-secret-key-change-me';
const DB_URL = 'postgres://admin:hunter2@db.prod.internal:5432/app';

Three secrets, three liabilities. Once this hits a repo, the secret is in your git history forever, even if you delete the line in a later commit. Public repos get scraped by bots within minutes. There are reports of freshly committed AWS keys getting used by attackers in under five minutes.

Why this keeps happening

LLMs learn from public code: tutorials, StackOverflow answers, sample apps. A huge amount of that code hardcodes secrets because it is meant to be illustrative, not production-ready. The model has no concept of "this value is sensitive." To it, the key string is just an argument like any other.

The model also optimizes for code that runs immediately. Reading from process.env requires the developer to set up a .env file first, so the path of least resistance for a working snippet is to inline the value.

The fix

Move every secret to an environment variable and load it at runtime:

// Secrets from environment - CWE-798 resolved
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
const JWT_SECRET = process.env.JWT_SECRET;
const DB_URL = process.env.DATABASE_URL;

Then keep the file out of git and scan before committing:

# .env (never commit this)
echo ".env" >> .gitignore

# Catch secrets before they are committed
npx gitleaks detect --source . --verbose

If a secret already made it into git history, changing the code is not enough. Rotate the key at the provider immediately, then scrub history with git filter-repo or BFG. Assume any committed secret is already burned.

A pre-commit hook is the real win here. The goal is to never let a secret reach a commit in the first place, because cleanup after the fact is painful and rotation is the only safe assumption.

I have been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags hardcoded secrets the moment the code is generated, before I move on to the next prompt. Its secrets scanner is built on Gitleaks and runs on the free tier with no signup. That said, even a plain pre-commit hook with gitleaks will catch most of what is in this post. The important thing is catching secrets early, whatever tool you use.

Ranked #1 on Google, Invisible in ChatGPT? Here's Why

Charles Kern — Mon, 15 Jun 2026 06:59:11 +0000

A marketing director I spoke with last month spent eighteen months and roughly $60K building out her content library. Her site ranks on page one for almost every keyword her team targets. Demos, comparison pages, the whole funnel. Clean.

Then a prospect told her he'd asked ChatGPT for the best tools in her category. Her brand wasn't mentioned. Not in the first answer. Not in the follow-up. Three of her competitors were.

She did everything right by the old rules. And the old rules quietly stopped covering a growing slice of how people actually find things.

Here's the part most people get backwards. They assume a strong Google ranking carries over to AI search. It doesn't. Ranking #1 on Google and being cited by ChatGPT are two different games with two different referees. Google rewards a page that earns clicks. An answer engine doesn't hand out clicks at all. It reads, synthesizes, and decides which sources are worth naming inside a generated answer. Those are not the same signal, and optimizing hard for one tells you almost nothing about the other.

The gap exists because of how these systems get their information. Some pull from a live index at the moment you ask. Others lean on what they absorbed during training, which can be a year or more stale. A few do both. When an answer engine builds a response, it isn't looking for the page with the most backlinks. It's looking for sources it can extract a clean, quotable, factual statement from, and sources it already understands as entities. If a model doesn't "know" your brand as a distinct thing in its world, it won't reach for you, no matter where you sit on Google.

This is also why Reddit threads and old forum posts get cited so often. They state things plainly. "I used X for six months, here's what broke." That's extractable. A glossy landing page that opens with "Reimagine your workflow" gives a model nothing to quote.

So what's actually happening when ChatGPT skips you? A few mechanical things, usually all at once.

Your pages may not be crawlable by AI bots. GPTBot, ClaudeBot, PerplexityBot, and Google-Extended are separate crawlers from the standard Googlebot. Plenty of sites block them in robots.txt without realizing it, sometimes because a security plugin or a default CDN rule did it for them. Open yoursite.com/robots.txt right now and look for User-agent: GPTBot. If you see Disallow: / under it, you've been invisible to OpenAI's crawler the entire time and nobody flagged it.

Your content may not contain a clean answer. Models prefer to quote a direct, self-contained statement. If the answer to "what does this product do" is spread across a hero banner, three feature cards, and a video, there's nothing for a model to lift cleanly.

Your brand may not exist as an entity. Answer engines build a mental map of who's who in a space. If your name only appears on your own domain and nowhere structured, you're a stranger. Competitors who show up in comparison articles, directories, and third-party roundups get understood as real players.

Here's what I'd do this week, in order.

Check your robots.txt for AI crawlers first. It's the cheapest fix and the most common silent killer. Unblock GPTBot, ClaudeBot, Google-Extended, and PerplexityBot unless you have a deliberate reason not to.

Add a direct answer block to your key pages. Fifty to eighty words, plain language, near the top: what the product is, who it's for, what it replaces. Write it so a stranger could quote one sentence and be correct.

Add FAQPage schema with five to eight real question-and-answer pairs on your important pages. Structured Q&A is some of the most extractable content you can publish, and it maps directly to how people phrase prompts. Here's the shape:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "What is [Product]?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "A 40-60 word plain answer a model can quote verbatim."
    }
  }]
}

Then go get mentioned off your own domain. Comparison posts, niche directories, genuine community threads, podcast show notes. Every structured, third-party reference makes you more legible as an entity.

Last, actually test it. Open ChatGPT, Perplexity, Claude, and Gemini and ask the questions your buyers ask. "Best [category] tools for [use case]." Write down who gets named and who doesn't. That list is your real scoreboard now, and most teams have never once looked at it.

I've been building XeniVue to close exactly this loop. It tracks where your brand shows up across ChatGPT, Perplexity, Claude, and Gemini, shows your Share of Voice against the competitors who keep getting cited instead of you, and audits your pages to explain why. If you want to see where you actually stand in AI search right now, that's the thing it was built to answer.

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.