SCAN YOUR CURSOR APP FOR VULNERABILITIES

Cursor is a VS Code fork with AI wired into everything: tab completions, Composer for multi-file edits, and an Agent mode that plans, edits, and runs commands on its own. What it produces is a conventional web app in whatever stack you prompted for — Next.js on Vercel, Express or Fastify APIs, FastAPI, Rails. Cursor the editor is not the attack surface; the app you deploy is.

The risk concentrates in the review gap. Composer can rewrite twenty files in one operation, and Agent mode can commit without a human reading the result. Teams accept the diff because it fixes the symptom they asked about — and miss what the diff quietly lacks: the auth middleware that never rejects, the parameterized query that became string concatenation, the CSRF check that vanished when a route “got faster.”

Rules files add their own leak path: keys pasted into .cursorrules “as a working example” go to the model on every prompt and sit in git history forever. A black-box scan of the deployed app catches what diff-skimming misses, because it tests behavior instead of reading code.

Common vulnerabilities we find in Cursor apps

Six shapes recur across Cursor-heavy repos and the apps they ship.

String-concatenated SQL

When Agent mode can’t infer your ORM — common in scripts and quick admin endpoints — it emits string-built queries that work perfectly against test fixtures:

const rows = await db.query(`SELECT * FROM users WHERE email = '${email}'`);

The exploit is classic injection: a crafted email parameter dumps the table. Search for f"SELECT, `SELECT ${, and + user_id +; every match should become a parameterized query ($1, ?, or ORM bindings), never manual quote-escaping.

Auth middleware that never rejects

A recurring Cursor scaffold: middleware that reads the session, finds none, and calls next() anyway. The route returns 200 with {user: null, items: []} — which looks like correct logged-out behavior in dev, but exposes the endpoint’s shape, admin fields included, to anyone.

Exploit: hit the API route directly with no auth header and read what comes back. Every auth middleware must end its negative path with return res.status(401).end(), and each one deserves a unit test asserting exactly that — otherwise the regression returns the next time Cursor refactors the file.

Broken object-level authorization (BOLA)

Generated CRUD routes authenticate the caller, then fetch by ID with no ownership check. Sign in as user B, replay user A’s request with A’s record ID, get A’s data. Because AI-generated frontends put real UUIDs in URLs and API calls, harvesting IDs takes minutes.

Add an owner_id comparison to every ID-keyed route:

if (record.owner_id !== req.user.id) return res.status(403).end();

The pattern and its variants are cataloged in BOLA in AI-generated CRUD.

Secrets in rules files and source

.cursorrules and .cursor/ files are sent to the model on every prompt, and developers paste real keys into them for context. Cursor also propagates example credentials it sees in nearby files — an .env.example value autocompletes into real source. Both roads end with sk-proj- or eyJ strings in the repo, the bundle, or a public GitHub search result.

Grep .cursor/, source, and the deployed bundle for key prefixes — and check history, since removal without rotation fixes nothing:

git log -p -- .cursorrules .cursor/ | grep -nE 'sk_|sk-proj-|eyJ|AKIA'

Unvalidated file uploads

Cursor’s first-pass upload handler trusts the browser: no size cap, no MIME allowlist, filename taken from the upload. That combination yields path traversal (../../ filenames), unbounded-storage DoS, and stored-payload hosting from your own domain.

Cap size, allowlist MIME by content sniff, and regenerate filenames server-side as UUIDs — the full failure catalog is in file upload, zip slip and XXE.

Permissive CORS and missing headers

cors() with no arguments or origin: '*' gets added to silence a dev-console error, then ships. Combined with credentialed requests, a hostile page can read authenticated API responses cross-origin. Generated apps also routinely omit CSP, HSTS, and X-Frame-Options entirely.

Set an explicit origin allowlist and add the header baseline once in middleware (helmet covers most of it in one line) — details in CORS and credentials misconfig.

How VibeEval works with Cursor

1. Enter your deployed URL. Production or a preview deploy — Vercel, Netlify, Railway, anywhere. No repo access needed; the scan sees exactly what an attacker sees.
2. The agent probes the running app. A browser-driven agent creates accounts, logs in, and works the app: replaying requests across users to find BOLA, hitting API routes directly to bypass client-side validation, inspecting bundles for leaked keys and source maps, and checking headers, CORS, and auth behavior on every endpoint it discovers.
3. You get a report built for the Cursor loop. Findings are ranked by severity with the evidence trail, and each includes a paste-ready fix prompt. Drop the prompt into Composer or Agent mode, review the diff, redeploy, re-scan.

Manual testing vs VibeEval

Honest framing: manual review remains the only way to judge whether the logic is right. The scanner’s edge is repeatability — Cursor edits code in every session, and re-running an identical attack suite after each one is something no team does by hand.

Frequently asked questions

Does VibeEval scan my source code?

No — VibeEval is black-box: it tests the deployed application the way an attacker would, with no repo access. That is the point: the vulnerabilities that matter are the ones reachable in production, and several (missing headers, leaked bundle secrets, BOLA) only manifest at runtime.

What frameworks does VibeEval support for Cursor apps?

All of them, because the scan is stack-agnostic. Whether Cursor wrote you Next.js, React + Express, Vue + FastAPI, or a Rails app, the deployed result speaks HTTP — and that is the layer where auth gaps, injection, CORS, and key leaks live.

When should I scan during a Cursor workflow?

After any Composer or Agent session that touched auth, data access, or payments — and always before promoting to production. Multi-file AI edits are precisely when security middleware regresses, and a scan of the preview deploy catches it before merge.

How is Cursor different from other AI tools for security?

The generated-code patterns are shared across AI coders; Cursor’s specifics are workflow-shaped. Composer’s large diffs invite skimming, Agent mode can commit unreviewed code, and .cursorrules files collect pasted secrets. See Is Cursor Safe? for the IDE-level analysis.

How do I fix the vulnerabilities VibeEval finds?

Each finding ships with a remediation prompt written for an AI coding agent. Paste it into Cursor, review the diff it produces (especially what it removes), redeploy, and re-scan to confirm the finding is gone.

Related Cursor resources

• How to Secure Cursor — the 12-step hardening guide: .cursorignore, Privacy Mode, MCP audit, branch protection, CI gates.
• Is Cursor Safe? — where the real risk lives: MCP permissions, Composer diffs, indexing, Agent autonomy.
• Cursor Security Checklist — pre-launch checklist for Cursor-authored code, from SQL parameterization to rules-file secrets.
• Token Leak Checker — free check for API keys exposed in your deployed bundle.
• Vibe Coding Vulnerabilities — the full taxonomy across AI coding tools.

Test your Cursor app before launch

Cursor writes code faster than anyone reviews it. Point VibeEval at your deployed URL and find the auth gaps, injectable queries, and leaked keys before launch — then paste the fixes straight back into the editor that caused them.