The secure vibe coding checklist

Secure vibe coding is not about slowing down. It is about running a deliberate pass before you ship — because vibe coding tools (Cursor, Claude Code, Lovable, Bolt, Windsurf, Replit) optimize for code that works, not code that is secure. They inline credentials to unblock integrations, skip authorization checks that the feature does not need to function, and reach for string concatenation before parameterized queries. In our scan of 976 real AI-built apps, 1 in 8 had a high-severity flaw. This checklist covers every category.

Why vibe coding produces predictable security gaps

The same models make the same tradeoffs every time they are asked to move fast. When Cursor needs a credential to wire up an integration, the path of least resistance is to write the literal value into the source file. When Lovable generates an API route, it creates the handler that satisfies the feature requirement — the server-side check that the caller owns the resource is not required for the feature to work, so it gets skipped. These are not random bugs. They are systematic patterns that appear in almost every AI-generated codebase, which means they are also fast to find and fix once you know what to look for.

Pass 1: secrets and credentials

This is the highest-blast-radius category and the fastest to check. Scan your full codebase and git history for API keys, connection strings, and credentials written directly into source. Use Prbl’s free secret checker to scan any public URL instantly, or read what happens when you push an API key to understand why rotation comes first.

• Search for patterns like sk_live_, ghp_, eyJ (base64-encoded JWT headers), postgres://, mongodb+srv://
• Check migration files, seed scripts, and config files — these are where AI tools most often inline real values
• Check git history, not just the current branch: git log --all --full-history -- "*.env"
• If any key appears in source or history, rotate it immediately — assume it was found
• Move all credentials to environment variables with no NEXT_PUBLIC_ prefix on server-only keys

Also check for fallback secrets in environment variable lookups — a pattern AI tools produce frequently:

// DANGEROUS: if JWT_SECRET is unset in production, this uses a predictable default
const secret = process.env.JWT_SECRET || 'dev-secret-change-me';

// CORRECT: fail loudly if the secret is missing rather than silently using a weak default
const secret = process.env.JWT_SECRET;
if (!secret) throw new Error('JWT_SECRET environment variable is required');

Pass 2: authentication and authorization

Missing auth checks are the most common finding in AI-generated code. There are two separate problems to check for:

• No auth check at all. The route returns or mutates data for any caller. Add a session check at the top of every route that handles user data.
• Auth without ownership check (BOLA). The route confirms the user is logged in, but returns any record regardless of who owns it. Every route that reads a specific record by ID must also verify the record belongs to the requesting user.

// VULNERABLE: checks auth but not ownership
app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id); // returns anyone's invoice
  res.json(invoice);
});

// CORRECT: checks both auth and ownership
app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await db.invoice.findOne({
    _id: req.params.id,
    userId: req.user.id, // must belong to the requesting user
  });
  if (!invoice) return res.status(404).json({ error: 'Not found' });
  res.json(invoice);
});

Pass 3: JWT handling

AI tools frequently generate code that decodes a JWT instead of verifying it. Decoding reads the payload with no secret key and no signature check — anyone can forge a token with any claims they want. Every route that trusts a JWT must use verify(), not decode():

// VULNERABLE: decode() does not check the signature
const payload = jwt.decode(token); // trusts any token unconditionally

// CORRECT: verify() checks the signature and throws on tampered or expired tokens
const payload = jwt.verify(token, process.env.JWT_SECRET, {
  algorithms: ['HS256'],
});

Full explanation: JWT decode vs verify.

Pass 4: database queries

• Replace every string-concatenated SQL or NoSQL query with a parameterized query or ORM method. See SQL injection from string concatenation.
• If using Supabase, enable Row Level Security on every table and verify an anonymous read returns nothing. Use the free Supabase RLS checker to confirm.
• Check that the service_role key is never in client code — it bypasses RLS entirely. Learn the difference: anon key vs service_role key.

Pass 5: wire it into CI so it stays clean

A one-time audit goes stale the moment you ship the next AI-generated feature. The only sustainable approach is continuous scanning:

• Add a scanner to your CI pipeline that runs on every pull request
• Configure it to comment on the PR with any new findings before merge
• Treat a HIGH finding like a failing test — do not merge until it is addressed

This also generates the audit trail that matters for SOC 2 and enterprise security questionnaires: months of evidence that findings are caught and fixed as a matter of routine.

Secure vibe coding: the pre-deploy checklist

Run through this before every production deploy:

• No API keys, connection strings, or JWT secrets in source files or git history
• No NEXT_PUBLIC_ prefix on server-only secrets
• No process.env.SECRET || 'fallback' patterns — fail loudly if a required var is missing
• Every API route that reads or writes user data has a server-side auth check
• Every route that fetches a record by ID checks that the record belongs to the requesting user
• JWT tokens are verified with jwt.verify(), not decoded with jwt.decode()
• No string-concatenated SQL queries — parameterized queries or ORM methods only
• Supabase RLS is enabled on every table and tested with an anonymous request
• The service_role key is only in server-side environment variables, never in client code
• A scanner runs on every pull request in CI before merge

Common questions