DEV Community

Cover image for Why Cursor Keeps Hardcoding Secrets in AI-Generated Code (CWE-798)
Charles Kern
Charles Kern

Posted on

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

#security #webdev #ai #devsecops

TL;DR

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

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

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

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

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

The vulnerable pattern (CWE-798)

Here is the kind of thing AI editors generate constantly:

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

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

Why this keeps happening

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

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

The fix

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

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

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

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

# Catch secrets before they are committed
npx gitleaks detect --source . --verbose
Enter fullscreen mode Exit fullscreen mode

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

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

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

Top comments (0)