Cursor app security: protect your secrets, your editor and your app

Two different things to secure

The app you build ends up on the internet, so leaked keys and open database rules are the main risk there. Your development environment is where the Cursor agent reads files, edits code and runs commands; prompt injection (instructions hidden in files, web pages or tool output) targets that side.

The typical risks

1. Secrets committed to the repo

Cursor's agent can write workspace files without approval (except configuration files), and changes save immediately. A key pasted into a prompt can end up hardcoded in a file and then in a commit. Review diffs before committing; see leaked API keys.

2. Secret files within the agent's reach

Cursor ignores .env* and anything in .gitignore by default, and you can add more paths in .cursorignore. Cursor's docs are explicit about the limits: the terminal and MCP tools used by Agent cannot block access to ignored files, and complete protection isn't guaranteed.

3. MCP configuration and known CVEs

CVE-2025-54135 (Cursor below 1.3.9) let the agent create a missing .cursor/mcp.json without approval, which a prompt injection could chain into code execution. CVE-2025-54136 (fixed in 1.3) let an attacker with write access to a shared repo swap an already-approved MCP server for a malicious command without a new prompt. Both are fixed; keep Cursor updated and treat changes to MCP files in pull requests as security-relevant.

4. Auto-run and untrusted repositories

Terminal commands need approval by default; Run Modes can relax that, but Cursor calls them best-effort guardrails, not a hard boundary. Workspace trust is disabled by default; Cursor suggests a basic text editor for untrusted repos.

5. Open database rules

If the app uses Supabase from the browser, check RLS on every table: Supabase RLS check.

What the free FixMyVibe scan checks

Paste the URL of a public GitHub repository. The free scan reads the code read-only on a temporary copy that is deleted afterwards, and looks for:

• Hardcoded secrets in the current files: API keys, tokens, Supabase secret/service_role keys, private keys, and secrets exposed through NEXT_PUBLIC_/VITE_ variables or committed build output.
• Supabase database rules in your committed SQL migrations: tables without RLS, USING (true)/WITH CHECK (true) policies, policies that trust user_metadata, and similar patterns.

What it does not do: it does not scan your git history (only the current files), it does not connect to your database or your live Cursor-built app, and it cannot see private repositories. Dependency checks against the OSV vulnerability database are part of the paid audits, not the free scan. It is an automated code scan, not a penetration test.

Pre-launch checklist

1. Update Cursor to the latest version (at least 1.3.9 for the MCP fixes).
2. Add secret paths (.env*, *.pem, credentials files) to .cursorignore or the global ignore list.
3. Keep terminal commands on approval unless you understand the Run Mode you pick.
4. Review new or changed MCP servers and .cursor/mcp.json changes before approving.
5. Review diffs for hardcoded keys before every commit; rotate anything that was exposed.
6. Check RLS on every Supabase table, then scan the repository.

FAQ

Sources

• Cursor docs: Agent security
• Cursor docs: Ignore file (.cursorignore)
• CVE-2025-54135 (CVE.org)
• Cursor advisory GHSA-4cxx-hrm3-49rm
• CVE-2025-54136 (CVE.org)
• Cursor advisory GHSA-24mc-g4xr-4395

FixMyVibe is an automated code scan, not a full penetration test, and cannot guarantee that an app is secure. What happens to your code during a scan: see our privacy policy.

Related guides

• Supabase RLS check
• Leaked API keys
• Claude Code app security
• Free security scan for AI-built apps