CURSOR SECURITY RISKS: 12 PATTERNS CURSOR-GENERATED CODE SHIPS WITH

The 12 Cursor security risks ranked by severity

Cursor’s full codebase awareness, multi-file editing, and agent autonomy ship faster than any human reviewer can keep up with. The result is a recurring set of vulnerabilities that turn up in nearly every Cursor-built app we scan.

Critical

1. Hardcoded secrets in source files

Cursor frequently suggests placing API keys, JWT secrets, database passwords, and webhook tokens directly in source files instead of environment variables. The pattern is especially strong when example credentials exist in nearby files — Cursor copies the structure verbatim.

Why it ships: Cursor’s codebase indexing sees example credentials, propagates them, and the developer accepts the diff without checking.

Fix prompt: “Audit this file for any hardcoded credentials, API keys, JWT secrets, or database URLs. Move every credential to a .env file referenced via process.env.X. Add .env to .gitignore if not already there.”

2. Missing authorization on CRUD endpoints (BOLA / IDOR)

Cursor generates GET /api/invoice/:id handlers that authenticate the user but don’t check whether the user owns invoice :id. Anyone with a valid session can read any invoice.

Why it ships: Cursor’s training data shows authentication checks far more often than authorization checks; the model defaults to “user is logged in = allowed.”

Fix prompt: “For every CRUD endpoint with a path parameter (/api/X/:id), add an ownership check: verify req.user.id matches the resource’s owner_id field before returning or modifying the resource. Return 403 if not.”

3. SQL injection via string concatenation

Despite the model knowing about parameterized queries, Cursor still produces db.query(\SELECT * FROM users WHERE email = ‘${email}’`)` for novel queries the developer described in chat.

Why it ships: Conversational requests for “complex queries” frequently produce template-literal SQL because the model thinks it’s clearer.

Fix prompt: “Replace every template-literal SQL query in this file with parameterized queries using the appropriate placeholder syntax for our DB driver. List the lines you changed.”

High

4. Over-permissive CORS

Access-Control-Allow-Origin: * set to silence development errors, then shipped to production with credentials enabled — a critical config that lets any origin read authenticated responses.

Fix prompt: “Set CORS origin to a configurable allowlist from process.env.ALLOWED_ORIGINS. Reject * for any endpoint that returns authenticated data. Verify Access-Control-Allow-Credentials: true is never combined with origin *.”

5. Missing input validation

Generated handlers trust user input without sanitization. Length not checked, type not validated, allowed values not constrained. Opens XSS, SQL injection, command injection.

Fix prompt: “Add input validation to every endpoint in this file using Zod (or our project’s validator). Define schemas for request body, query, and params. Return 400 on validation failure with a sanitized error message.”

6. Verbose error handlers exposing internals

Generic catch (e) { res.json(e) } ships database error messages, stack traces, and internal paths to attackers.

Fix prompt: “Replace every error handler that returns the raw error with a structured handler that logs the full error server-side, returns a generic message to the client, and includes a correlation ID. Never expose stack traces or DB errors externally.”

High-Medium

7. Missing rate limiting

Auth endpoints, password reset, and expensive queries shipped without rate limits. Enables credential stuffing and resource exhaustion.

Fix prompt: “Add rate limiting to all auth endpoints (login, signup, password-reset, refresh) using express-rate-limit (or our framework’s equivalent). 5 requests per minute per IP for auth, 100/min for general API.”

8. JWT signature verification skipped or wrong

Cursor sometimes generates jwt.decode() (unverified) instead of jwt.verify(). Or uses none algorithm. Tokens become trivially forgeable.

Fix prompt: “Audit all JWT handling in this codebase. Ensure every token is verified with jwt.verify() using a server-side secret. Reject the none algorithm. Verify iss, aud, and exp claims explicitly.”

9. Webhooks without signature verification

Cursor generates webhook handlers that trust whatever request comes in. Stripe, Slack, GitHub all sign webhooks; the verification is skipped.

Fix prompt: “For every webhook handler, add signature verification using the provider’s documented method (Stripe-Signature, X-Hub-Signature-256, etc.). Reject any request that fails verification with 401. Use a constant-time comparison for the signature check.”

Medium

10. Secrets in client-side bundle

Cursor sometimes places process.env.X in client-side code, which Webpack/Next.js inlines into the public bundle. Server secrets ship to every visitor.

Fix prompt: “Audit every process.env.X reference in client-side files. For each, confirm the variable is intended to be public (Next.js prefix NEXT_PUBLIC_, Vite prefix VITE_). Move any secret to server-only code paths.”

11. Insecure dependencies

Cursor suggests packages by name. Sometimes those packages don’t exist (hallucinated dependencies — see package hallucination) or have known CVEs.

Fix prompt: “Run npm audit (or pnpm audit) and fix all high/critical vulnerabilities. For any package that fails to resolve, replace with the actual official package or remove the dependency.”

12. Debug routes in production

/admin, /_debug, /health shipped without auth gates. Common when Cursor generates scaffold during development and the dev forgets to remove or gate before deploy.

Fix prompt: “List every route in this codebase that should not be publicly accessible. Add authentication middleware to each. Remove any pure debug routes that have no production purpose.”

How to use this list

Run a scan to find which patterns are present in your specific app — listing them generically is cheap, finding them in your code is the work. The Vibe Code Scanner tests for all 12 patterns above plus 300 others, in under 60 seconds.

For each finding, paste the matching fix prompt into Cursor. Run the scan again to verify the fix.

Cursor-specific risks beyond generated code

The 12 above cover code Cursor generates. Cursor the IDE also adds risks at the workflow level:

• MCP server permissions — see Is Cursor Safe? for MCP configuration.
• Codebase indexing of secrets — .cursorignore is not optional.
• Composer multi-file edits — review every diff or require PR.
• Agent mode autonomy — never let Agent push to main directly.

For the full IDE-level audit, see Is Cursor Safe? — Security Analysis.

Cursor enterprise risk profile

Enterprise teams using Cursor’s Business plan should layer on:

• Admin policy enforcement (Privacy Mode required, model allowlist)
• SSO / SAML
• Required PR review for AI-generated commits
• CI security gate (this page’s 12 patterns + dynamic scan)
• Quarterly extension audit

For enterprise specifics, see Cursor Enterprise Security.

Related resources

• Is Cursor Safe? — IDE-level security audit
• How to Secure Cursor — step-by-step hardening
• Cursor Enterprise Security — Business plan controls
• Vibe Coding Vulnerabilities — full taxonomy across all AI tools
• OWASP Top 10 for AI Code
• Copilot Security Risks — comparable analysis for GitHub Copilot
• Vibe Code Scanner — automated scanner for all 12 patterns