← Guides
Going-live guide · Cursor

Vibe-coding with Cursor: the bugs it quietly ships

Cursor is a different kind of vibe-coding: you’re directing an AI inside a real editor, so what ships depends heavily on what you ask — and what you don’t. It’s brilliant at producing working code fast. It’s also happy to take the insecure shortcut when your prompt doesn’t rule it out. Here are the patterns that quietly reach production.

It takes the shortcut you didn’t forbid

Ask Cursor to “make this query work” and it may add using (true) to your row-level security, skip an auth check, or drop a validation — because that’s the shortest path to “it works.” It isn’t malicious; it’s optimizing for your immediate prompt, not for an adversary.

Check: Did any “fix” loosen a security control to make something pass? Re-read the diffs around auth, database policies and input handling.

It doesn’t hold your whole architecture

Cursor works in the file or selection in front of it. Cross-cutting concerns — consistent tenant isolation, auth enforced everywhere, secrets kept server-side — are exactly the things that slip when each change is local and the model never sees the whole picture at once.

Check: Is the tenant/ownership check applied everywhere a record is read or written — or only where you remembered to ask for it?

”Looks done” is its specialty

Cursor produces code that compiles, runs, and reads cleanly. None of that tells you it’s safe. A passing build is not a security review.

Check: Has anyone read the code asking “where does this break for a hostile or second user?” — rather than “does it run?”

Secrets and quick client-side calls

If you paste an API key while iterating, or ask for a fast client-side call to a paid API, Cursor will wire it up — in the client, where it’s public.

Check: Any secret that should be server-side sitting in frontend code or env that ships to the browser?

Most Cursor apps are Next.js or Supabase under the hood

So the stack-specific failure modes apply too — leaked NEXT_PUBLIC_ secrets and unguarded route handlers on Next.js, open RLS and the service_role key on Supabase.

Before you go live

  • Re-read diffs around auth, RLS/rules and validation — did any get loosened to “make it work”?
  • Tenant/ownership checks applied consistently, server-side, everywhere.
  • No secret in client code.
  • A read by someone who didn’t write it — the one thing the author and the AI can’t do for themselves.

Common questions

Does Cursor write secure code?

Cursor writes what you ask — and will take the insecure shortcut (open row-level security, a skipped auth check, a secret in client code) when your prompt doesn't rule it out. It optimizes for the immediate change, not for an adversary, so code headed to production still needs a human security review.

What do I need to check in a Cursor-built app before launch?

Re-read the diffs around auth, database rules and validation for shortcuts that loosened a control to make something pass; confirm tenant and ownership checks are applied everywhere, server-side; keep secrets out of client code; and have someone who didn't write it read it. Most Cursor apps are Next.js or Supabase under the hood, so those stack-specific checks apply too.

// Cursor · before real users

Have a senior engineer read your Cursor app before launch.

A real human reads your actual code and tells you what breaks — prioritized, in 48 hours. $49, one-time.

Get your audit $49