How to Secure an App Built with Cursor

Cursor is everywhere. It hit $2 billion in annual revenue by early 2026 and became the default IDE for a generation of developers who build with AI. Tab complete, accept, tab complete, accept. Ship.

But Cursor has a unique security profile that's different from browser based tools like Lovable or Bolt.new. It runs on your machine, has access to your filesystem, executes code, and connects to external MCP servers. The attack surface isn't just the code it generates, it's the tool itself.

In December 2025, security researcher Ari Marzouk disclosed 30+ vulnerabilities across AI coding tools, including two critical Cursor specific CVEs. The code Cursor generates also carries the same issues found in all AI generated code, 45% vulnerability rate according to Veracode.

This guide covers both: securing the tool and securing what it builds. For broader context, see our [complete guide to vibe coding security](/learn/vibe coding security).

The Cursor specific CVEs you need to know about

CVE 2025 54135, CurXecute

This one is bad. A malicious .cursor/mcp.json file in a cloned repository could trigger remote code execution without user approval. You clone a repo, open it in Cursor, and the attacker's code runs on your machine.

The attack path: a .cursor/mcp.json file defines MCP (Model Context Protocol) servers that Cursor connects to. A crafted config could point to an attacker controlled server that executes arbitrary commands through Cursor's agent capabilities.

CVE 2025 54136, MCPoison

This vulnerability allowed persistent backdoors through MCP server modification. An attacker could modify MCP server responses to inject malicious instructions that persist across sessions. Even after you close and reopen Cursor, the compromised MCP server continues to influence code generation.

What this means for you

If you use MCP servers with Cursor, and many developers do for database access, API testing, or deployment, you need to treat them as a trusted attack surface. Only connect to MCP servers you control or explicitly trust.

Immediate actions:

1. Update Cursor to the latest version (these CVEs are patched)
2. Review your .cursor/mcp.json, do you recognize every server listed?
3. Never open untrusted repositories in Cursor without checking for .cursor/ directory contents first

Issue 1: MCP server risks

MCP servers give Cursor powerful capabilities, database queries, API calls, file system access, deployment commands. They're also a vector for supply chain attacks.

A compromised or malicious MCP server can:

• Read your environment variables and secrets
• Execute commands on your machine
• Modify generated code to include backdoors
• Exfiltrate data through seemingly normal API calls

The fix

Audit your MCP configuration and apply least privilege:

// .cursor/mcp.json, audit this file carefully
{
  "mcpServers": {
    "database": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server"],
      "env": {
        // Only pass the minimum required credentials
        "SUPABASE_URL": "https://your-project.supabase.co",
        // Use a service role key only if necessary
        // Prefer the anon key for read-only operations
        "SUPABASE_ANON_KEY": "your-anon-key"
      }
    }
  }
}

Rules for MCP servers:

• Only install MCP servers from verified sources
• Review the source code of any MCP server before connecting
• Use read only credentials where possible
• Never put production database credentials in MCP configs during development
• Add .cursor/mcp.json to your .gitignore if it contains credentials

# Add to .gitignore
echo ".cursor/mcp.json" >> .gitignore

Issue 2: .cursorrules injection

.cursorrules is Cursor's project level configuration file. It tells the AI how to behave for your project, what frameworks to use, coding style preferences, and generation rules.

The problem: if you clone a repository with a malicious .cursorrules file, it silently changes how Cursor generates code for that project. An attacker could instruct Cursor to:

• Skip input validation on all generated forms
• Use eval() or other unsafe functions
• Install specific npm packages (that could be compromised)
• Send data to external endpoints in generated API calls
• Disable security features in generated configs

You wouldn't notice because Cursor follows the instructions seamlessly, it's doing exactly what the rules say.

The fix

Always review .cursorrules when cloning a repository:

# Check for .cursorrules in any repo you clone
cat .cursorrules 2>/dev/null || echo "No .cursorrules file"

# Also check for the newer .cursor/rules directory
ls -la .cursor/rules/ 2>/dev/null || echo "No .cursor/rules directory"

Create your own security focused .cursorrules file and use it as your project default:

# .cursorrules, Security-first configuration

## Security requirements (always apply)

### Input validation
- Validate and sanitize ALL user input on the server side
- Use parameterized queries for all database operations, never string concatenation
- Validate data types, lengths, and formats before processing

### Authentication and authorization
- Implement all auth checks server-side (middleware, RLS policies, or API route guards)
- Never rely on client-side route protection as a security measure
- Use secure session management with httpOnly, secure, sameSite cookies
- Implement proper CSRF protection on all state-changing endpoints

### Secrets management
- Never hardcode API keys, tokens, or passwords in source code
- Never use NEXT_PUBLIC_ or VITE_ prefixes for sensitive environment variables
- Store secrets in environment variables loaded server-side only
- Add .env files to .gitignore

### Security headers
- Always include Content-Security-Policy headers
- Always include X-Frame-Options: DENY
- Always include X-Content-Type-Options: nosniff
- Always include Strict-Transport-Security for HTTPS sites
- Always include Referrer-Policy: strict-origin-when-cross-origin

### API security
- Add rate limiting to all API endpoints
- Implement proper error handling that doesn't leak internal details
- Return generic error messages to clients, log detailed errors server-side
- Validate Content-Type headers on all endpoints

### Dependencies
- Do not install packages without explicit user approval
- Prefer well-maintained packages with large download counts
- Never use deprecated or archived packages

Issue 3: Code generation without review

This is the core vibe coding problem, and Cursor makes it especially easy. Tab complete, accept. Tab complete, accept. The code flows so fast that reviewing each generation feels like it defeats the purpose.

But Cursor generated code has the same issues as all AI generated code:

• Auth logic in components, not middleware: Cursor generates React/Next.js route guards that only run client side
• SQL injection via string concatenation: especially in raw query builders
• Missing input validation: forms that pass user input directly to APIs
• Overly broad error handling: catch(e) {} that swallows errors and hides security issues
• Insecure defaults: CORS set to *, cookies without secure flags, permissive CSP

The Stanford study found that developers using AI assistants wrote less secure code and were more confident it was secure. Cursor's speed amplifies this: you generate more code per hour, review less of it, and trust the AI more.

The fix

You don't need to review every line. Focus on the security critical paths:

1. Always review auth logic manually:

// RED FLAG: Client-side only auth check
export default function AdminPage() {
  const { user } = useAuth();
  if (!user?.isAdmin) return redirect('/');
  // ...
}

// BETTER: Server-side middleware (Next.js example)
// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  // Verify session server-side
  return NextResponse.next();
}

export const config = {
  matcher: ['/admin/:path*', '/api/admin/:path*'],
};

2. Always review database queries:

// RED FLAG: String concatenation in query
const result = await db.query(
  `SELECT * FROM users WHERE email = '${email}'`
);

// BETTER: Parameterized query
const result = await db.query(
  'SELECT * FROM users WHERE email = $1',
  [email]
);

3. Always review API route handlers:

Check for: input validation, auth checks, rate limiting, error handling, and CORS configuration.

Issue 4: Accepting code without understanding it

Cursor's autocomplete is addictive. It suggests entire functions, and pressing Tab is faster than thinking about what the code does. Over time, your codebase accumulates code you didn't write and don't fully understand.

This is a security problem because:

• You can't secure code you don't understand
• Vulnerabilities hide in complexity
• Refactoring becomes risky when you're not sure what things do

The fix

Use Cursor's own features to help:

• Ask Cursor to explain generated code before accepting it: "explain what this function does and what security implications it has"
• Use Cursor's inline chat to ask: "are there any security issues with this code?"
• Set up a precommit hook that runs basic security checks:

#!/bin/bash
# .git/hooks/pre-commit, basic security checks

# Check for hardcoded secrets
if grep -rn "sk-proj-\|sk_live_\|sk_test_\|password.*=.*['\"]" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" src/; then
  echo "ERROR: Potential hardcoded secret detected. Review before committing."
  exit 1
fi

# Check for eval usage
if grep -rn "eval(" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" src/; then
  echo "WARNING: eval() usage detected. This is a security risk."
  exit 1
fi

echo "Security pre-commit checks passed."

The Cursor security checklist

1. Update Cursor: Make sure you're on the latest version with CVE patches
2. Audit MCP servers: Review .cursor/mcp.json, remove anything you don't recognize
3. Add a security .cursorrules: Use the template above as your project default
4. Review auth and database code: Never blindly accept generated auth logic or queries
5. Check cloned repos: Review .cursorrules and .cursor/ directory before opening in Cursor
6. Add precommit hooks: Automated checks catch what manual review misses
7. Scan your deployed app: Run it through AmIHackable to catch what got through

The output still needs scanning

Cursor is the best AI coding tool available. That's exactly why it's important to understand its security model. The better the tool, the more code it generates, the more surface area for vulnerabilities.

The code Cursor writes is good. It's just not automatically secure. Add the .cursorrules template, review the critical paths, and scan your app before deploying. That combination covers the vast majority of issues.

---

Sources: IDEsaster, 30 CVEs in AI IDEs (2025) · Veracode GenAI Code Security Report (2025) · Stanford, Do Users Write More Insecure Code with AI Assistants? (2023) · Databricks, Passing the Security Vibe Check (2025)