Cursor-Generated Code Review Checklist: 11 Checks Before You Merge

Last updated: October 2026 · 9 min read

By the Ingenious AI team

Cursor generates code in your editor, in your repo, at your speed, which means its output skips the review rituals that used to catch mistakes. The code looks native. It compiles. The tests pass. But "the AI wrote it in my codebase" is not a review. Here are the ten checks a security-minded reviewer runs on Cursor-generated code before merging, mapped to the exact detectors Vibe-Code Audit applies.

1. Secrets the model pasted for convenience

Cursor happily writes const STRIPE_KEY = "sk_live_…" when your prompt implies it. It also copies real keys from your existing files into new ones, propagation, not just creation.

Scanner mapping: the secrets check class, 32 patterns on Pro (AWS, GitHub, Stripe, OpenAI, Supabase, Twilio, private keys, JWT), with per-secret blast radius and rotation runbooks.

2. Tainted flows: input → sink, proven

The highest-value review question: does untrusted input reach a dangerous sink? Cursor writes both ends correctly in isolation and connects them badly.

Scanner mapping: taint tracking (Pro) proves data flow from request input to sink with no sanitizer in between. Proven flows top the Top Risks ranking, severity × proven reachability.

3. SQL built by concatenation

Cursor-generated data layers mix parameterized queries and f-string SQL in the same file. One is safe; the other is a breach.

# VULNERABLE
query = f"SELECT * FROM docs WHERE owner = '{owner}'"

# FIXED
query = "SELECT * FROM docs WHERE owner = %s"
cur.execute(query, (owner,))

Scanner mapping: SQL injection risk, plus second-order injection (Pro) for the stored-then-executed variant.

4. XSS in the frontend it generated

dangerouslySetInnerHTML, innerHTML refs, unescaped template literals, the usual suspects, generated with confidence.

Scanner mapping: the XSS check class, with taint tracking (Pro) separating real flows from theoretical ones.

5. String-to-code sinks

eval, exec, new Function, string arguments to setTimeout, Cursor generates these when prompts ask for "dynamic" behavior.

Scanner mapping: eval usage, code injection, and setTimeout check classes.

6. Prototype pollution (JS/TS)

Recursive merge utilities, config parsers, and query-string handlers are pollution vectors: __proto__ keys that rewrite every object's behavior. Cursor writes these helpers from scratch instead of using vetted libraries.

Scanner mapping: the advanced prototype pollution detector (Pro) hunts the non-obvious shapes, deep-merge loops, path setters, JSON key handling, that keyword scans miss.

7. Deserialization of untrusted data

pickle.loads, yaml.load, marshal, generated for "load the uploaded file" or "restore session" tasks.

Scanner mapping: unsafe deserialization, plus deserialization gadget chains (Pro) for multi-class exploit chains.

8. The imports it invented

Cursor autocompletes import statements. Sometimes the package doesn't exist (hallucinated), is days old (newborn), or is a lookalike of a real one (typosquat). npm install / pip install then pulls attacker code into your build, slopsquatting.

Scanner mapping: SlopSquat Shield (Pro) verifies every import live against npm/PyPI and names the real package the AI probably meant.

9. Prompt-injection sinks (if it built agent features)

If Cursor generated any LLM feature, chat, summarizer, tool-using agent, check where untrusted text (webpages, uploads, tool outputs) meets the prompt. Concatenated prompts are injection sinks.

Scanner mapping: LLM prompt-injection sinks, insecure LLM output handling, RAG poisoning, and tool-call injection (Pro), the agent-threat layer most scanners don't cover. Full breakdown in our LLM-threat pillar.

10. JWT handling it wrote from memory

Auth code generated from training data is where the subtle bugs live: accepting alg: none, fetching verification keys from the token's own jku header, using kid as a file path, or accepting HS256 with an RSA public key.

Scanner mapping: the JWT key confusion advanced detector (Pro): jku/x5u trust, kid injection, and RS256↔HS256 algorithm confusion.

11. Composer and agent-mode edits across files you didn't open

Everything above assumes you asked Cursor for code and got code. Agent mode is different: you describe an outcome, and Cursor edits files across your repo, runs commands, and iterates until the tests pass. The output isn't a diff you requested. It's a session.

Review these sessions differently. First, get the full file list: every file the agent touched, not just the ones related to your request. Agents fix adjacent things. They update a shared utility "while they're in there." They bump a dependency to resolve a conflict they created. Each of those is an unreviewed change with your name on the commit.

Second, check what the agent did to make the tests pass, not just that they pass. An agent under pressure to green the suite will weaken assertions, skip flaky tests, or mock the thing that was failing. We covered the mirror problem in why AI code passes tests but fails human review: agent mode automates it. Read the test diff with the same suspicion as the code diff.

Third, check for credentials the agent handled along the way. Agent sessions that touch auth, deployment configs, or API integrations routinely print secrets into terminal output, write them into scratch files, or paste them into generated code "temporarily." Temporary has a way of becoming permanent in a repo. Search the session's touched files for key-shaped strings before you merge, not after.

The rule for agent mode is the same as for Replit Agent: the session is a junior developer's PR with no description. Full diff, every file, before merge. The ten checks above still apply to each file; this eleventh check is about the files you didn't know were involved.

The merge checklist

☐ No hardcoded secrets (scan the diff, not just new files)
☐ Tainted inputs traced to every sink; sanitizers in place
☐ All SQL parameterized; no string-built queries
☐ No unescaped HTML rendering of user content
☐ No eval/exec/new Function/string timers
☐ Merge/config utilities guard __proto__
☐ No deserialization of untrusted blobs
☐ Every new dependency verified on npm/PyPI
☐ LLM features: untrusted text never concatenated into prompts
☐ JWT verification pinned to known keys and algorithms

Run all ten in one pass: paste your Cursor-generated code into Vibe-Code Audit. Free tier covers the fundamentals; Pro ($49 one-time) adds taint tracking, SlopSquat Shield, and the 16 advanced detector families, including the agent-threat layer no other scanner in this price class covers.

Review your Cursor code free →

FAQ

Should I scan every Cursor generation or just the big ones?

Scan the diff before every merge. Security bugs in AI code cluster at the seams, auth, input handling, serialization, new dependencies, which is exactly what a diff review covers.

How do I get fixes back into Cursor?

Every finding includes copy-paste fix guidance, including a prompt you can paste into Cursor's chat to regenerate the code correctly. Scan → paste prompt → re-scan to verify the fix.

Does the free tier cover the checklist?

Checks 1–5 and 7 run on Free. Taint tracking, SlopSquat Shield, and the advanced detectors (prototype pollution, gadget chains, JWT confusion, the LLM-threat layer) are Pro.

Is this a replacement for human review?

No, it's the first pass that makes human review affordable. The scanner catches the pattern-level issues in seconds so your review time goes to architecture and business logic, not hunting eval.

Turning the checklist into Cursor rules

The checklist works best when you don't have to remember it. Cursor lets you save project rules that the agent reads before writing code — put the highest-signal items there and the model stops generating the findings in the first place. Three rules cover most of the list: never hardcode secrets (read them from environment variables), never use innerHTML or dangerouslySetInnerHTML with interpolated data, and verify every new npm package against the registry before importing it.

Rules don't replace review; they shrink it. When the model stops emitting the easy findings, your review time goes to the things only a human catches: whether the auth model matches the product's actual trust boundaries, whether error paths leak information, whether the "temporary" workaround has a removal date. Run the generated diff through the scanner, read what it flags, and keep a short log of which findings repeat — that log becomes next month's rules update.