Cursor Security Review: The 12-Point Pre-Production Checklist

What This Checklist Covers

Cursor security review is the process of auditing AI-generated code for vulnerabilities before shipping to production. Per Endor Labs' March 2026 analysis, Cursor is secure as an IDE — but the code it generates creates attack vectors that traditional security tools can't handle. This 12-point checklist covers the specific vulnerabilities that emerge when using Cursor at scale: prompt injection, supply chain attacks, credential leaks, and the production hardening gaps AI doesn't fill.

Run this checklist before every production deployment of Cursor-generated code.

Part 1: IDE-Level Security (3 checks)

Before reviewing the code, verify your Cursor environment is configured securely.

Check 1: Workspace Trust Enabled

What to verify: Cursor's Workspace Trust feature is enabled and configured to only trust repositories from verified sources.

Why it matters: CVE-2026-26268 (February 2026) demonstrated that malicious repositories can trigger arbitrary code execution on developer machines. Workspace Trust creates a boundary between trusted and untrusted projects.

How to verify:

1. Open Cursor Settings (Cmd/Ctrl + ,)
2. Search "Workspace Trust"
3. Verify "Trust Only Verified Sources" is enabled
4. Review your list of trusted workspaces

Pass criteria: Workspace Trust enabled, only known repositories trusted.

Check 2: Cursor Rules Audited

What to verify: Any .cursorrules files in your project are reviewed and authored by your team.

Why it matters: Per Endor Labs, project-specific rules files can be weaponized. A malicious rules file in a cloned repository can contain hidden instructions that execute automatically, influencing all AI interactions within that workspace.

How to verify:

# Find all Cursor rules files
find . -name ".cursorrules" -o -name ".cursor*"

# Review each file for unexpected instructions
cat .cursorrules

Pass criteria: All rules files are authored by your team, contain no external URLs, and include no system commands.

Check 3: Privacy Mode Enabled (If Required)

What to verify: If your project contains sensitive code, Privacy Mode prevents code from being stored on Cursor servers.

How to verify:

1. Open Cursor Settings
2. Search "Privacy Mode"
3. Verify enabled for sensitive projects

Pass criteria: Privacy Mode enabled for projects with proprietary code, customer data, or security-sensitive logic.

Part 2: Dependency Security (3 checks)

AI models suggest packages based on training data, not current security intelligence.

Check 4: No Typosquatting Packages

What to verify: All installed packages are legitimate, not typosquatted versions of popular libraries.

Why it matters: Per Endor Labs, 40% of AI-generated code introduces vulnerable dependencies. Cursor can't detect typosquatting attacks where package names are slight misspellings of legitimate ones.

How to verify:

# Compare package names against known good versions
npm ls --all | head -50

# Check for suspicious package names
# Look for: lodsh (lodash), reactt (react), expresss (express)

Common typosquatting targets:

• lodash → lodassh, lodahs, 1odash
• express → expresss, expres, expr3ss
• axios → axois, axi0s, axio
• react → reactt, reakt, r3act

Pass criteria: All package names verified against official npm registry.

Check 5: Dependencies Pinned to Safe Versions

What to verify: package-lock.json or yarn.lock exists and specifies exact versions.

Why it matters: Without lock files, builds can pull different dependency versions, potentially introducing vulnerabilities discovered after Cursor suggested the package.

How to verify:

# Verify lock file exists
ls package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# Run dependency audit
npm audit

Pass criteria: Lock file committed, npm audit shows 0 critical/high vulnerabilities.

Check 6: No Deprecated or Unmaintained Packages

What to verify: All dependencies have recent activity and no known deprecation notices.

Why it matters: Cursor's training data may include packages that were popular in 2024 but abandoned by 2026.

How to verify:

# Check for deprecated packages
npm outdated

# Verify package health on npm
# Look for: last publish date, weekly downloads, open issues

Pass criteria: All dependencies published within last 12 months, no deprecation warnings.

Part 3: Code-Level Security (4 checks)

These checks apply to the AI-generated code itself.

Check 7: No Hardcoded Secrets

What to verify: Generated code contains no API keys, tokens, passwords, or credentials.

Why it matters: Per Endor Labs, AI can leak secrets by pulling from training data. Generated test files and boilerplate code are highest risk.

How to verify:

# Search for common secret patterns
grep -rn "sk_live\|sk_test\|AKIA\|AIza\|ghp_\|gho_\|password\s*=" src/

# Search for hardcoded tokens
grep -rn "Bearer \|api[_-]?key\s*[=:]\|secret\s*[=:]" src/

# Verify no .env values in code
grep -rn "$(cat .env | grep -v '^#' | cut -d= -f2)" src/ 2>/dev/null

Pass criteria: No matches for secret patterns in source code.

Check 8: Database Queries Use Parameterization

What to verify: All database queries use parameterized statements, not string concatenation.

Why it matters: SQL injection remains the #1 web vulnerability. AI-generated queries may concatenate user input.

How to verify:

// WRONG: String concatenation
const query = `SELECT * FROM users WHERE id = ${userId}`;

// CORRECT: Parameterized
const query = 'SELECT * FROM users WHERE id = $1';
await db.query(query, [userId]);

Search for vulnerable patterns:

grep -rn 'SELECT.*\${' src/
grep -rn 'INSERT.*\${' src/
grep -rn 'UPDATE.*\${' src/
grep -rn 'DELETE.*\${' src/

Pass criteria: No string-concatenated SQL queries; all use parameterization.

Check 9: User Input Sanitized

What to verify: All user-generated content is sanitized before rendering.

Why it matters: XSS vulnerabilities let attackers execute scripts in other users' browsers.

How to verify:

# Search for dangerouslySetInnerHTML without sanitization
grep -rn "dangerouslySetInnerHTML" src/

# Verify DOMPurify or similar sanitization in use
grep -rn "DOMPurify\|sanitize\|escapeHtml" src/

Pass criteria: Every dangerouslySetInnerHTML is paired with DOMPurify sanitization.

Check 10: Error Handlers Don't Leak Internals

What to verify: Error responses don't expose stack traces, internal paths, or system information.

Why it matters: Verbose error messages help attackers map your system architecture.

How to verify:

// WRONG: Leaking internals
catch (error) {
  return Response.json({ error: error.message, stack: error.stack });
}

// CORRECT: Generic response
catch (error) {
  console.error(error); // Log internally
  return Response.json({ error: 'An error occurred' }, { status: 500 });
}

Pass criteria: No stack traces or internal paths in error responses.

Part 4: Production Hardening (2 checks)

These patterns apply to any production deployment.

Check 11: Security Headers Configured

What to verify: Response headers include XSS protection, frame options, and content security policy.

How to verify:

// next.config.ts should include
const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Content-Security-Policy', value: "default-src 'self';" },
];

Test in production:

curl -I https://yourapp.com | grep -i "x-frame\|x-content\|csp\|referrer"

Pass criteria: All four security headers present in responses.

Check 12: Rate Limiting on Auth Endpoints

What to verify: Login, registration, and password reset endpoints are rate-limited.

Why it matters: Without rate limiting, attackers can brute-force credentials at thousands of attempts per second.

How to verify:

// Middleware should include rate limiting
import { Ratelimit } from '@upstash/ratelimit';

// Test: 100 rapid requests should trigger 429
for i in {1..100}; do
  curl -s -o /dev/null -w "%{http_code}\n" https://yourapp.com/api/auth/login
done | grep 429 | wc -l
# Should show rate limiting kicked in

Pass criteria: Auth endpoints return 429 after 10-20 rapid requests.

Scoring Your Security Review

Scoring:

• 90-100 points: Production-ready. Ship it.
• 70-89 points: High-risk gaps. Fix before launch.
• 50-69 points: Multiple vulnerabilities. Requires immediate remediation.
• Below 50: Do not deploy. Start with a Production Audit.

The Production Lift: Security Review + Remediation

If your Cursor-generated code fails multiple checks, the Production Lift implements all remediation in one week for €3,500 fixed:

Included:

• Full security audit (all 12 checks + additional coverage)
• Production-grade auth (NextAuth v5 or Clerk)
• Multi-tenant Row-Level Security (Postgres RLS)
• Security headers + CSRF + rate limiting
• Playwright e2e test suite (≤15 spec files)
• Sentry + Vercel Analytics
• 30-day post-ship bug fix window

The same playbook that shipped wintura.ai.

Frequently Asked Questions

How often should I run this checklist?

Run the full checklist before every production deployment. Run checks 4-6 (dependency security) weekly. Run checks 7-10 (code security) on every PR that includes Cursor-generated code.

Do I need this if I'm using Cursor's Privacy Mode?

Privacy Mode protects your code from being stored on Cursor servers. It doesn't scan for vulnerabilities, verify dependencies, or add production hardening. You need both.

What about automated scanning tools?

Traditional SAST and SCA tools help but don't cover AI-specific risks like prompt injection, context poisoning, or training data leakage. Use them in addition to this checklist, not instead of it.

Does this checklist apply to Copilot, Bolt, and other AI tools?

The code-level and production hardening checks (7-12) apply to any AI-generated code. The IDE-level checks (1-3) are Cursor-specific. See Lovable to Production: The 18-Point Checklist for Lovable-specific coverage.

---

Need help remediating security issues? The Production Audit (€1,500, 3 days) delivers a severity-ranked PDF report covering all 12 checks plus additional coverage. If you commit to the Production Lift within 30 days, the audit fee converts.