Cursor security review: closing the gaps AI leaves open

What makes Cursor different — and where it creates risk

Cursor is not a code generator in the way Bolt.new or Lovable are. It is an IDE. Experienced developers use it. The code it produces is higher quality, closer to what a senior engineer would write, and integrated into an existing codebase rather than starting from scratch.

Those distinctions matter for the threat model. The security risks in Cursor-assisted codebases are different from AI-generated-from-scratch apps. They do not come from scaffolding defaults being wrong. They come from three specific dynamics:

1. Pattern amplification. Cursor's completions optimize for consistency with your existing codebase. If your codebase has insecure patterns, Cursor will produce more code following those patterns — faster, and at scale.
2. Configuration file contamination. Cursor's context files (.cursorrules, .cursor/rules/) are often committed to version control with sensitive content that was never intended to be there.
3. Velocity without gate. Cursor makes it easy to ship quickly. Teams that adopt it often inadvertently remove the review steps that caught security issues before.

We have reviewed codebases where Cursor was the primary development tool for 6–18 months. The findings are consistent enough to document here as a category.

1. Tab completions that amplify insecure patterns

Cursor's Autocomplete and Composer features are trained on your codebase context. This is the source of their utility — they produce code that fits your conventions, uses your naming, and integrates with your architecture. It is also the source of the pattern-amplification risk.

Consider a codebase where one engineer wrote a database query using string concatenation three years ago:

// An old query in /lib/db.ts
const query = `SELECT * FROM orders WHERE user_id = '${userId}'`;

When a developer asks Cursor to write a new query for a different table in the same file, or in a file that imports the same pattern, Cursor will frequently complete using the same string interpolation approach. The model is doing its job — it is being consistent with the codebase. The output is SQL injection risk propagated to the new query.

We have seen this pattern with SQL injection, cross-site scripting (raw innerHTML assignments in one file causing Cursor to suggest them in others), missing input validation, and insecure direct object references (fetching records by user-supplied ID without verifying ownership).

// src/api/reports.ts — Cursor-propagated from existing pattern
const report = await db.query(
  `SELECT * FROM reports
   WHERE id = '${reportId}'     -- ← string interpolation, not parameterized
   AND status = 'published'`
);

// Correct: parameterized query
const report = await db.query(
  `SELECT * FROM reports
   WHERE id = $1
   AND status = 'published'`,
  [reportId]  // ← value passed as parameter, never interpolated
);

2. Secrets in .cursorrules and Cursor configuration

Cursor's context system allows you to place project-specific instructions, codebase descriptions, and architectural notes in .cursorrules (legacy) or .cursor/rules/*.mdc files. The AI uses these to produce more relevant, contextually appropriate suggestions.

In practice, teams put things in these files they should not: database connection strings (so Cursor can see the schema), API endpoints with authentication tokens embedded, internal service URLs, and even literal credentials — on the theory that giving Cursor the right context will produce better suggestions.

The security problem is that these files are frequently committed to version control. A .cursorrules file with a database URL, a Stripe secret key, or an internal admin endpoint URL is a file that belongs in .gitignore, not in the repository. If the repository ever becomes accessible — through a misconfigured GitHub visibility setting, a team member's forked copy, or a third-party CI integration — those secrets are exposed.

# .cursorrules — committed to repository
# Project: MyApp
# Database: PostgreSQL via Supabase
# Supabase URL: https://abcdefgh.supabase.co
# Supabase service role key: eyJhbGciOiJIUzI1NiIsInR5cCI6Ikp...  ← DO NOT COMMIT
# Stripe secret key: sk_live_51...                                 ← DO NOT COMMIT
# Use these for context when generating database queries and payment logic.

# .gitignore — add these lines
.cursorrules
.cursor/
.env
.env.*
!.env.example

3. No pull request review step before deploy

This is a process gap, not a code gap, but it is the most common finding in Cursor-using teams that have not explicitly addressed it. Cursor makes individual developers so productive that the natural impulse is to accelerate the entire delivery pipeline — including removing the review step before production deploys.

We have seen multiple codebases where the deploy pipeline triggers on direct pushes to main, with no branch protection, no required reviewer, and no automated security scan. The developer writes code in Cursor, commits, pushes, and it is live. The speed is real. So is the risk: a single Cursor suggestion that introduces a vulnerability ships directly to production, unreviewed.

The specific risk is amplified because Cursor is completing and suggesting — not just implementing explicit instructions. A developer may accept a suggestion without reading it carefully, particularly in files they are less familiar with. Without a second reviewer, that suggestion can introduce a vulnerability without anyone consciously noticing.

# .github/workflows/deploy.yml — current state
on:
  push:
    branches: [main]   # ← triggers on direct push, no PR gate

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - run: vercel deploy --prod   # ← direct to production, no security scan

# .github/workflows/security.yml — add this workflow
name: Security scan
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep ci --config=p/owasp-top-ten --config=p/secrets
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

The Cursor-specific security review checklist

1. Audit your .cursorrules and .cursor/ directory. Check every file for credentials, connection strings, API keys, and internal service URLs. Remove them. Add the directory to .gitignore. Purge git history if any were committed.
2. Run gitleaks on the full repository history. gitleaks detect --source=. --log-opts="--all". Review every finding. Rotate any credential found.
3. Search for interpolated SQL. grep -rn "db.query\(\`\|pool.query\(\`" src/. Every template literal in a query call needs inspection. Replace with parameterized queries.
4. Search for innerHTML assignments. grep -rn "innerHTML" src/. Each one is a potential XSS vector if the content comes from user input or an API response. Replace with safe DOM manipulation or a sanitizer.
5. Enable branch protection. Require at least one reviewer and passing security scan status checks on main. Make direct push to main impossible for all team members, including maintainers.
6. Add a Semgrep step to CI. Run semgrep --config=p/owasp-top-ten --config=p/secrets on every pull request. Block merge on any finding above severity P2.
7. Audit .env files in the repository. Search for .env files that are tracked by git: git ls-files | grep ".env". Every .env file except .env.example (which should contain no real values) should be in .gitignore.
8. Review IDOR patterns. Search for database queries that fetch records by a user-supplied ID without checking that the ID belongs to the requesting user. This is the pattern Cursor most frequently propagates incorrectly.

What Cursor gets right, and where the responsibility sits

Cursor does not introduce security vulnerabilities. It amplifies and propagates what is already present in your codebase, and it removes friction from a development process that may have needed that friction. The responsibility for the security of the output is the developer's, not the tool's.

This matters because the right fix for Cursor security is not to use Cursor less. It is to add the gates that Cursor's speed makes it tempting to remove: branch protection, automated scanning in CI, and a deliberate review of the patterns you have already established in your codebase before you let an AI amplify them at scale.

This guide reflects patterns observed in Cursor-assisted codebases as of 2026. Cursor product behavior may change. This is general guidance, not a security guarantee. For production systems handling regulated data, engage a qualified security assessor. Contact: info@launchreadycode.com · launchreadycode.com