Why Cursor Skips Auth Middleware on Every Route It Generates

#security #webdev #ai #devsecops

TL;DR

AI editors consistently generate new routes without auth middleware, even when the rest of the codebase has it
CWE-862 (Missing Authorization) is one of the most common findings in vibe-coded Express and FastAPI backends
Fix: apply auth at router or app level -- never rely on AI to add it per-route

I've been reviewing side projects lately. Friends sending me "almost ready to ship" Node/Express apps built mostly with Cursor. Three out of four had the same problem. Fresh routes, zero auth middleware.

Not a single authenticate call. No requireAuth. Just wide-open handlers waiting for someone to enumerate user IDs.

The annoying part: the existing routes in the codebase had auth. The AI saw those. It just didn't carry the pattern forward to new endpoints it generated.

The Pattern That Keeps Showing Up

Here's what Cursor typically produces when you ask it to add a user data endpoint (CWE-862: Missing Authorization):

app.get('/api/users/:id/profile', async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json(user);
});

app.get('/api/users/:id/settings', async (req, res) => {
  const settings = await Settings.findOne({ userId: req.params.id });
  res.json(settings);
});

No auth check. No ownership check. Anyone who knows (or guesses) a user ID can read that user's profile and settings. The ID is often sequential or a predictable UUID -- IDOR waiting to happen.

Why AI Keeps Generating This

LLMs learn from tutorials and Stack Overflow. Most tutorial code shows the happy path -- getting a resource, returning it. Auth is always "added later," usually as a separate section.

The model sees thousands of routes without middleware for every one with it, especially in early-stage code examples. It defaults to omission over assumption because auth middleware is contextual -- it doesn't know if your middleware is called authenticate, requireLogin, or authGuard.

There's also a subtler issue: when you ask Cursor to "add a settings endpoint," you're framing a feature request. The AI answers that question. Auth wasn't part of the question.

The Fix

Apply auth at the router level, not per-route:

// Router-level middleware -- every route below this line is protected
const userRouter = express.Router();
userRouter.use(authenticate);

userRouter.get('/:id/profile', async (req, res) => {
  if (req.user.id !== req.params.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const user = await User.findById(req.params.id);
  res.json(user);
});

userRouter.get('/:id/settings', async (req, res) => {
  if (req.user.id !== req.params.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const settings = await Settings.findOne({ userId: req.params.id });
  res.json(settings);
});

app.use('/api/users', userRouter);

Or apply a global default-deny approach -- safer because new routes are protected automatically:

app.use((req, res, next) => {
  const publicPaths = ['/api/auth/login', '/api/auth/register', '/api/health'];
  if (publicPaths.includes(req.path)) return next();
  return authenticate(req, res, next);
});

With default-deny, you opt routes out of auth rather than opting them in. AI can generate all the routes it wants -- they're locked down until you explicitly open them.

Rate Limiting on Auth Endpoints

Missing auth is bad. Missing rate limiting on the login endpoint is worse. Here's what AI typically generates:

// No rate limiting -- brute force welcome
app.post('/api/auth/login', async (req, res) => {
  const user = await User.findOne({ email: req.body.email });
  const valid = await bcrypt.compare(req.body.password, user.password);
  if (!valid) return res.status(401).json({ error: 'Invalid credentials' });
  const token = jwt.sign({ id: user.id }, process.env.JWT_SECRET);
  res.json({ token });
});

Fix with express-rate-limit:

import rateLimit from 'express-rate-limit';

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

app.post('/api/auth/login', authLimiter, loginHandler);
app.post('/api/auth/register', authLimiter, registerHandler);

Ten attempts per 15 minutes. Enough for legitimate users. Brute force becomes impractical.

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.

DEV Community