HOW TO SECURE CURSOR: 12-STEP HARDENING GUIDE

How to secure Cursor in 12 steps

The work splits into three layers: what Cursor sees (codebase indexing, MCP, extensions), what Cursor’s output ships (review gates, branch protection, CI), and what reaches production (dynamic scan on deploy). Skip any layer and the others can’t compensate.

Cursor is an IDE-native agent stack: Tab completion, Chat, Composer, Agent, and MCP. Each multiplies throughput. Each also multiplies the rate at which a bad auth pattern or leaked key can land on main if you only trust the diff highlighter.

Layer 1 — Lock down what Cursor sees (5-minute setup)

Step 1. Create a .cursorignore for every repo

Cursor’s codebase indexer ingests every file in the working tree by default — including .env, secrets in config, infrastructure-as-code with embedded credentials, and customer-data fixtures. Without an ignore file, all of this gets sent to the AI model on every completion.

Create .cursorignore at the repo root:

# Secrets
.env
.env.*
*.pem
*.key
*.p12
*.pfx
secrets/
config/credentials.json
config/production.json
config/staging.json

# Infrastructure
terraform.tfvars
*.tfstate
*.tfstate.backup

# Customer data fixtures
fixtures/customers.json
fixtures/users.json
seeds/production.sql

# Build artifacts (also reduces noise)
node_modules/
.next/
dist/
build/

Verify in Cursor: open the file, confirm Cursor shows “Ignored” status.

Expand the ignore list when you add new secret-bearing paths (Stripe CLI config, gcloud ADC files, kubeconfig, .aws/credentials if ever in-repo). A quarterly git ls-files | grep -iE 'secret|credential|key|env' catches drift.

Step 2. Enable Privacy Mode

Settings → General → Privacy Mode → enabled.

Privacy Mode prevents Cursor from retaining code or training on it. Code still transits to the AI model for completions, but it isn’t stored server-side. For sensitive codebases, this is non-negotiable.

For Business plan: enforce at org level — Admin console → Policies → “Require Privacy Mode” → enable.

Privacy Mode does not stop a developer from pasting a production dump into Chat. Policy still matters.

Step 3. Audit MCP servers

Open ~/.cursor/mcp.json (macOS/Linux) or %APPDATA%\Cursor\mcp.json (Windows). List of every MCP server enabled. Each runs with full user permissions on your machine.

For each entry: confirm you installed it, confirm you still use it, confirm the source publisher is trusted. Remove anything you can’t account for.

MCP is remote code execution with your privileges. Prefer read-only tokens for GitHub/Slack MCP servers; never point MCP at production databases with write roles for casual coding sessions.

// Prefer scoped tokens via env, not hard-coded secrets in mcp.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GH_READ_TOKEN}" }
    }
  }
}

Step 4. Audit installed extensions

Cursor inherits VS Code’s extension model — every extension runs with full IDE trust. Run extension audit:

Cmd/Ctrl+Shift+P → "Extensions: Show Installed Extensions"

Review the list. Remove unused. Prefer verified-publisher extensions for anything that touches your codebase (formatters, linters, AI tools).

Disable auto-update in high-security environments until changelogs are reviewed. A compromised extension updates quietly.

Layer 2 — Gate what Cursor’s output ships (workflow controls)

Step 5. Branch protection on main

Cursor’s Composer and Agent modes can land multi-file changes quickly. Without branch protection, those changes can reach main (and CI auto-deploy) without human review.

GitHub: Settings → Branches → main → Require pull request before merging → Require approvals (at least 1, ideally code owners).

GitLab equivalent: Settings → Repository → Push Rules + Protected Branches.

CODEOWNERS on **/auth/**, **/payments/**, .github/workflows/** forces the right reviewers when Composer touches high-risk paths.

Step 6. Required PR review on AI-generated commits

Configure a PR template that asks contributors to disclose AI-generated portions. Code reviewers focus on those sections especially.

.github/pull_request_template.md:

## AI-Generated Code

- [ ] This PR contains code generated by Cursor / Claude Code / other AI tools
- [ ] AI-generated portions noted in commit messages
- [ ] Security-sensitive sections reviewed (auth, payments, data access)

## Security checklist

- [ ] No new hardcoded secrets
- [ ] Input validation on every new endpoint
- [ ] Authorization (not just authentication) on resource access
- [ ] Error handlers don't expose stack traces

Step 7. CI security gate

Add a security scan to CI that blocks merge on critical findings. Static scan + dynamic scan if your deploy preview supports it.

GitHub Actions example:

- name: Security scan
  run: |
    # Static: secret detection
    npx gitleaks detect --source . --report-format sarif
    # Dependency audit
    npm audit --audit-level=high
    # Custom rules for AI-generation patterns
    npx semgrep --config=auto --error

For dynamic scan against the deployed preview, see Vibe Code Scanner — runs as a CI step against your preview URL.

Semgrep custom rules for Cursor-shaped bugs (NEXT_PUBLIC_*SECRET*, USING (true), open CORS) pay off quickly. See SAST tools for AI code.

Step 8. Disable Composer auto-accept

Composer can write multiple files at once. The diff viewer is correct but tedious; teams accept changes without reading every file.

Settings → Composer → require explicit accept per file (verify exact setting name in your version). Slows the workflow; catches the diff that nobody would have read.

Especially never auto-accept changes under middleware, auth, payments, IaC, and workflow YAML.

Step 9. Run Agent mode in feature branches only

Agent mode runs autonomously and can commit. Configure it to operate only in feature branches, never directly on main. Combined with step 5, Agent commits land in PRs that require review.

If Agent can run terminal commands, watch for curl | sh, broad rm, and package installs. Approve shell deliberately.

Layer 3 — Scan what reaches production

Step 10. Dynamic security scan on every deploy

Static scans catch some patterns; dynamic scans (against the running app) catch the rest — the BOLA / IDOR / RLS / CORS issues that only surface at runtime.

Add a dynamic scan step to your deploy pipeline:

- name: Dynamic security scan
  run: |
    curl -X POST https://app.vibe-eval.com/api/scan \
      -H "Authorization: Bearer ${{ secrets.VIBEEVAL_TOKEN }}" \
      -d '{"url": "${{ env.PREVIEW_URL }}"}' \
      --fail

Block deploy on critical findings. Most teams set “block on Critical, alert on High.”

Step 11. Quarterly .cursorignore review

Codebases grow. New secret-bearing files get added. The .cursorignore you wrote in step 1 needs to grow too.

Quarterly: git ls-files | grep -iE 'secret|credential|key|password|env' to find files you might have missed.

Step 12. Monthly MCP and extension audit

Repeat steps 3 and 4 monthly. New MCP servers get installed during exploration; old extensions accumulate. Audit, prune, lock down.

Put the audit on a calendar invite. Optional work does not happen.

The 12-step setup as a single command

For a fresh repo, the layer-1 setup is one block of work:

# Create .cursorignore from template
cat > .cursorignore <<'EOF'
.env
.env.*
*.pem
*.key
secrets/
config/credentials.json
terraform.tfvars
*.tfstate
fixtures/customers.json
EOF

# Add PR template
mkdir -p .github
# (copy the template from step 6)

# Enable git hook for secret scanning
npm install --save-dev gitleaks
echo 'npx gitleaks protect --staged' >> .husky/pre-commit

Common mistakes when securing Cursor

Skipping .cursorignore because “I’ll remember not to share secrets” — Cursor’s codebase indexing happens automatically, on every keystroke. Manual remembering doesn’t apply.

Treating Privacy Mode as the only control — Privacy Mode only addresses retention. The model still sees the code; the security of the code Cursor generates is separate.

Trusting the AI to add auth checks because the prompt mentioned auth — AI generates what gets prompted, often missing the secondary check (auth without authorization). Required PR review is the gate.

Believing static scan in CI is enough — Static analysis catches some patterns; dynamic scan against the deployed app catches the rest. Use both.

Configuring policies but not enforcing them — Business plan policies bind only when SSO is required; without enforcement, individual users can opt out.

Installing MCP servers from blog posts without reading the package — MCP is remote code execution under your user. Treat each server like a root-capable plugin.

Letting Composer rewrite CI or auth “to make tests pass” — the agent sometimes weakens assertions or removes middleware. Diff those files carefully.

Pastes of production .env into Chat — Privacy Mode does not make that safe.

Patterns Cursor ships most often

These show up repeatedly in Composer output across stacks:

1. Auth without authorization — requireAuth present; no owner_id === session.userId.
2. NEXT_PUBLIC_ / VITE_ secrets — so the browser can “see the key.”
3. CORS * — to silence a local frontend/backend port mismatch.
4. SQL / ORM string concat from training data examples.
5. Unvalidated webhooks — Stripe/GitHub handlers that trust the body.
6. Package hallucination — npm install of a name that does not exist (or exists as malware).
7. Verbose 500s in production error handlers.
8. Missing rate limits on login, signup, and LLM proxy routes.

When reviewing a Cursor PR, search the diff for those eight before debating style.

# Quick hostile grep on a branch
git diff main...HEAD | grep -nE 'NEXT_PUBLIC_.*(SECRET|KEY)|dangerouslySetInnerHTML|USING \(true\)|cors\(\{ origin: .?\*'

Composer / Agent session runbook

1. Create a feature branch with a narrow ticket.
2. Confirm .cursorignore and Privacy Mode.
3. Disable unnecessary MCP for the session.
4. Prefer small Composer tasks over “rewrite the app.”
5. Read every file in the multi-file accept list.
6. Run tests locally; re-run security tests if the agent “fixed” failures.
7. Open PR with AI disclosure.
8. After preview deploy, dynamic scan.

Abort if the agent starts editing production Terraform with live credentials in the workspace.

How to verify Cursor hardening

Team rollout plan (2 weeks)

Week 1 — Local defaults

• Ship a company .cursorignore template into every repo.
• Require Privacy Mode in the handbook (and org policy if Business).
• Ban auto-merge for Composer/Agent branches.
• Document approved MCP servers.

Week 2 — Pipeline

• Add gitleaks + Semgrep + npm audit as required checks.
• Add dynamic scan against preview URLs for apps with auth/data.
• Schedule monthly MCP/extension review on the calendar.
• CODEOWNERS on auth/payments/workflows.

Solo founders: do Layer 1 the same day you install Cursor; add CI before public launch. See the solo founder pre-launch checklist.

Cursor vs Claude Code vs Cline (security)

Hardening ideas transfer; the control names differ. If you use more than one agent, standardize on ignore files, secret scanning, and dynamic deploy scans across all of them.

Rules and .cursorrules hygiene

Project rules (.cursorrules / project instructions) steer generation. Keep them security-positive:

- Never commit secrets; use env vars.
- Every new HTTP route requires auth middleware and ownership checks.
- Prefer parameterized queries; no string-built SQL.
- Do not weaken CI security jobs to make tests pass.
- New Supabase tables ship with RLS in the same change.

Beware malicious or overly aggressive rules checked into third-party templates — review rules files like code. See indirect prompt injection when rules pull remote content.

Composer sessions without shipping BOLA

Composer optimizes for “feature complete.” Add a standing rule: every new endpoint ships with a negative authz test. If Composer cannot write the test, the endpoint is not done.

.cursorrules worth keeping

- Never commit secrets; use environment variables.
- Every API route authenticates and authorizes ownership.
- No dangerouslySetInnerHTML with user content.
- Prefer parameterized queries; no string-built SQL.
- Do not weaken or delete existing security tests.

Review rules files in forked repos before opening them — malicious rules are a real path.

Dependency and supply chain (1)

Lockfiles, immutable CI installs, pinned GitHub Actions, and verification of packages the model suggests. Hallucinated package names are a real path. On guides cursor changes that touch package manifests, require a human to open the registry page once.

# smoke verification sketch for guides/cursor
curl -s -o /dev/null -w '%{http_code}\n' "$PREVIEW_URL/healthz"

Human process and training (2)

New engineers should break a demo app on purpose, fix it, and rescan. That training beats a PDF policy. For guides cursor, keep one golden path example of a secure change and one of a rejected insecure change in internal docs.

// deny-by-default sketch used near guides/cursor
export function assertOwner(userId: string, ownerId: string) {
  if (userId !== ownerId) throw new Error('forbidden');
}

Operational checklist for guides cursor (3)

Treat guides cursor as a production surface with an owner, a review cadence, and a verification step after every AI-assisted change. Write the owner name in the repo SECURITY.md. Schedule a monthly re-read of controls that touch authentication, secrets, and data access. When an agent opens a PR against this area, require dual-user tests and a preview scan before merge. Keep a short incident appendix: which keys to rotate, which dashboards to check, who communicates with users.

Common AI-generator mistakes on guides cursor (4)

Generators optimize for demos: open data paths, client-trusted roles, missing rate limits, and secrets in env files that ship to browsers. On guides cursor, re-check those classes after every feature prompt. Search diffs for deleted middleware, new admin routes, and dependency adds. Reject ’temporarily disable auth’ comments without a tracking ticket and expiry.

# smoke verification sketch for guides/cursor
curl -s -o /dev/null -w '%{http_code}\n' "$PREVIEW_URL/healthz"

Verification commands and proofs (5)

Proof beats intention. For guides cursor, keep a script or checklist that demonstrates deny paths: anonymous access fails, user A cannot read user B, webhooks reject bad signatures, and bundles lack server secrets. Store the last run date next to the checklist. If the date is older than your release cadence, you are flying blind.

CI and release gates (6)

Encode the minimum bar in CI so humans do not renegotiate under launch pressure: secret scan, dependency audit, unit tests including authz negatives, preview deploy, live security scan failing on criticals. For guides cursor-related paths, add CODEOWNERS so reviews land on people who understand the threat model.

// deny-by-default sketch used near guides/cursor
export function assertOwner(userId: string, ownerId: string) {
  if (userId !== ownerId) throw new Error('forbidden');
}

Environment separation (7)

Production credentials must not appear in previews or local agent sandboxes. Separate projects or branches for data stores, separate OAuth redirect allowlists, and separate Stripe test vs live keys. Document the matrix where coding agents can read it so ‘make preview work’ does not copy prod secrets again.

# smoke verification sketch for guides/cursor
curl -s -o /dev/null -w '%{http_code}\n' "$PREVIEW_URL/healthz"

Logging, monitoring, and abuse (8)

Log authentication failures, authorization denials, and high-cost endpoints with request ids. Alert on spikes. Rate limit auth and AI proxy routes. For guides cursor, define what ‘abnormal’ looks like before an attacker teaches you under load.

Dependency and supply chain (9)

Lockfiles, immutable CI installs, pinned GitHub Actions, and verification of packages the model suggests. Hallucinated package names are a real path. On guides cursor changes that touch package manifests, require a human to open the registry page once.

Human process and training (10)

New engineers should break a demo app on purpose, fix it, and rescan. That training beats a PDF policy. For guides cursor, keep one golden path example of a secure change and one of a rejected insecure change in internal docs.

# smoke verification sketch for guides/cursor
curl -s -o /dev/null -w '%{http_code}\n' "$PREVIEW_URL/healthz"

// deny-by-default sketch used near guides/cursor
export function assertOwner(userId: string, ownerId: string) {
  if (userId !== ownerId) throw new Error('forbidden');
}

Operational checklist for guides cursor (11)

Treat guides cursor as a production surface with an owner, a review cadence, and a verification step after every AI-assisted change. Write the owner name in the repo SECURITY.md. Schedule a monthly re-read of controls that touch authentication, secrets, and data access. When an agent opens a PR against this area, require dual-user tests and a preview scan before merge. Keep a short incident appendix: which keys to rotate, which dashboards to check, who communicates with users.

Common AI-generator mistakes on guides cursor (12)

Generators optimize for demos: open data paths, client-trusted roles, missing rate limits, and secrets in env files that ship to browsers. On guides cursor, re-check those classes after every feature prompt. Search diffs for deleted middleware, new admin routes, and dependency adds. Reject ’temporarily disable auth’ comments without a tracking ticket and expiry.

Verification commands and proofs (13)

Proof beats intention. For guides cursor, keep a script or checklist that demonstrates deny paths: anonymous access fails, user A cannot read user B, webhooks reject bad signatures, and bundles lack server secrets. Store the last run date next to the checklist. If the date is older than your release cadence, you are flying blind.

# smoke verification sketch for guides/cursor
curl -s -o /dev/null -w '%{http_code}\n' "$PREVIEW_URL/healthz"

CI and release gates (14)

Encode the minimum bar in CI so humans do not renegotiate under launch pressure: secret scan, dependency audit, unit tests including authz negatives, preview deploy, live security scan failing on criticals. For guides cursor-related paths, add CODEOWNERS so reviews land on people who understand the threat model.

// deny-by-default sketch used near guides/cursor
export function assertOwner(userId: string, ownerId: string) {
  if (userId !== ownerId) throw new Error('forbidden');
}

Environment separation (15)

Production credentials must not appear in previews or local agent sandboxes. Separate projects or branches for data stores, separate OAuth redirect allowlists, and separate Stripe test vs live keys. Document the matrix where coding agents can read it so ‘make preview work’ does not copy prod secrets again.

Logging, monitoring, and abuse (16)

Log authentication failures, authorization denials, and high-cost endpoints with request ids. Alert on spikes. Rate limit auth and AI proxy routes. For guides cursor, define what ‘abnormal’ looks like before an attacker teaches you under load.

# smoke verification sketch for guides/cursor
curl -s -o /dev/null -w '%{http_code}\n' "$PREVIEW_URL/healthz"

Dependency and supply chain (17)

Lockfiles, immutable CI installs, pinned GitHub Actions, and verification of packages the model suggests. Hallucinated package names are a real path. On guides cursor changes that touch package manifests, require a human to open the registry page once.

Related resources

• Is Cursor Safe? — IDE-level audit
• Cursor Security Risks — 12 patterns in Cursor-generated code
• Cursor Enterprise Security — Business plan controls
• Vibe Coding Vulnerabilities — full vulnerability taxonomy
• Vibe Code Scanner — automated dynamic scan
• Token Leak Checker — finds secrets in deployed bundles
• Package Hallucination Scanner — finds AI-invented dependencies
• OWASP Top 10 for AI Code
• How to Secure Claude Code — parallel agent hardening
• How to Secure Cline — open-source agent controls