Skip to content
BuildThenTestedSee packages

Cursor app security: defaults, what breaks, what to check

Cursor is an AI code editor and coding agent that edits files and runs terminal commands on the developer's machine. Below: what it configures by default according to its own documentation (verified 2026-09-21), the 15 patterns most associated with it, the security features the vendor offers and where they stop, and a checklist you can run without buying anything.

Cursor is an editor, not an app builder with hosting; stack, hosting and database rules are whatever the developer and the generated project choose.

Cursor is an AI code editor and agent. It does not choose your stack or host your app; it writes code into your project and, with your approval, runs commands. Terminal commands need approval by default, .env files are ignored by default, and network access from agents is limited.

Testing a Cursor-built app is testing the app, not the editor: whatever stack the project uses is where the patterns live. The patterns listed here are the ones that appear in generated code across stacks, plus two documented Cursor issues that matter if you let the agent open untrusted content.

What Cursor sets up by default

Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.

Defaults of Cursor as documented by the vendor
AreaDefaultSource
FrontendCursor is an editor and agent; it does not choose a stack. The docs describe it as a coding agent for understanding codebases, planning features, fixing bugs and reviewing changes.docs · verified 2026-09-21
HostingCursor does not host or deploy apps; code runs locally or where the developer deploys it. Terminal changes execute immediately on disk.docs · verified 2026-09-21
Command approvalBy default terminal commands need your approval; file reading and code search do not. Run Modes range from an allowlist to an Auto-review classifier, described as best-effort guardrails rather than a hard boundary.docs · verified 2026-09-21
Secrets / env vars.env* files are ignored by default, along with node_modules, .git, lock files and media, so Agent, Tab and Inline Edit do not read them.docs · verified 2026-09-21
Network accessAgents cannot make arbitrary network requests by default; permitted destinations include GitHub, direct link retrieval and web search providers.docs · verified 2026-09-21
Source accessCode stays in the developer's repository; with Privacy Mode enabled, customer data is not used for training and model providers operate under zero data retention agreements.docs · verified 2026-09-21

Documentation home: cursor.com/docs

What breaks in Cursor apps

52 patterns in the catalogue name Cursor; the most severe are listed here across secrets and keys, data access, login and permissions, payments. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.

Public incidents

Two days after announcing a SaaS built with Cursor and no hand-written code, its founder reported subscription bypasses, maxed-out API keys and unwanted database writes; he shut the app down three days later.

  • 2025-03-15 Launch announcement
  • 2025-03-17 Report of subscription bypass and API key abuse
  • 2025-03-20 Shutdown announcement

Mar 2025 · Leo (Enrichlead founder) · all sources

Cursor below version 1.3.9 created workspace files without approval, so a prompt injection in content the agent read could write a .cursor/mcp.json file and run attacker commands (CVE-2025-54135, CVSS 8.6).

  • 8.6 High CVSS 3.1 base score
  • Cursor 1.3.9 Fixed in
  • 2025-08-05 CVE published

Aug 2025 · CVE Program (GitHub CNA) · all sources

In Cursor versions before 1.3, an MCP server configuration approved once could later be changed to a different command, for example in a shared repository, and would run without a new prompt (CVE-2025-54136, CVSS 7.2).

  • 7.2 High CVSS 3.1 base score
  • Cursor 1.3 Fixed in
  • 2025-08-01 CVE published

Aug 2025 · CVE Program (GitHub CNA) · all sources

Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.

  • 2026-02-03 to 2026-04-20 Exposure window
  • 2026-02-22 First HackerOne report
  • about 2 hours Time from public report to fix

Apr 2026 · Lovable · all sources

Each entry links to its primary source in the evidence list. What to do about it is the self-check below.

Cursor's own security features, and where they stop

Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.

  • Privacy Mode

    When enabled, Cursor does not train on your data and applies technical and contractual controls with model providers; available to all users.

    Where it stops: Providers may still run abuse classifiers, and flagged prompts may be stored for investigation, per the privacy overview.

    vendor docs · verified 2026-09-21

  • Sandboxed terminal (Run Modes)

    Sandboxing runs shell commands with read and write access inside the workspace and network blocked by default, using Seatbelt on macOS and Landlock plus seccomp on Linux (kernel 6.2+). Auto-review is the recommended default since Cursor 3.6.

    Where it stops: Some commands need full system access and bypass the sandbox; the classifier can allow a call you would have blocked.

    vendor docs · verified 2026-09-21

  • .cursorignore

    Blocks listed files from Agent, Tab, Inline Edit and @ mentions; .env* files are ignored by default.

    Where it stops: Terminal and MCP server tools used by Agent cannot be blocked by .cursorignore.

    vendor docs · verified 2026-09-21

  • Bugbot

    Reviews pull request diffs for bugs, security issues and code quality problems and leaves comments with fix suggestions.

    Where it stops: Usage-based billing; Cursor project rules in .cursor/rules do not apply to Bugbot runs.

    vendor docs · verified 2026-09-21

Check it yourself, in this order

The critical patterns first. Each uses the dashboard and your browser.

NEXT_PUBLIC_ prefix on a secret

  1. In your hosting dashboard (Vercel: Project, Settings, Environment Variables) or your .env files, list every variable whose name starts with NEXT_PUBLIC_.
  2. For each one, ask whether the provider calls that value secret, private, server or admin. Stripe secret keys, model provider keys, database passwords and Supabase service_role keys all fall in that group.
  3. Open the live site in Chrome, right-click, choose Inspect, open the Sources tab and press Ctrl+Shift+F. Search for the first few characters of each suspect value.
  4. A bad result is a NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script.

Secrets committed to the code repository

  1. Open your project on GitHub (or the code view in your builder) and look at the file list for .env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.
  2. Use the repository search box and search for sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.
  3. If you have the code on your computer, run one command in the project folder: git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.
  4. On GitHub, open Settings, then Code security, and check whether Secret scanning shows alerts.
  5. A bad result is any env or key file in the file list, any search hit that shows a real key, or an open secret scanning alert.

Service-role key shipped in the browser bundle

  1. Open your live app in Chrome, right-click anywhere and choose Inspect, then open the Sources tab.
  2. Press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search every loaded file. Search for service_role and then for sb_secret_.
  3. Open the Network tab, reload the page, click any request whose address contains supabase.co, and read the apikey header under Request Headers.
  4. In the Supabase dashboard, open Project Settings, then API Keys, and compare that header value with your keys.
  5. A bad result is any search hit, or a header value that matches the service_role or secret key rather than the anon or publishable key.

Cursor pre-launch checklist

52 checks, in the order we run them. Usable without buying anything.

Self-check tool

Answer questions about your app and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.

Run the self-check

Packages for Cursor apps

Pre-launch check

Start here

For founders about to let real users in.

$490

Report in 48 hours
  • Keys and secrets in the browser or repo
  • Who can read and change whose data
  • Login, roles and admin routes
  • Errors, retries and rate limits
  • Debug mode, headers, deploy path

What you receive

Security sweep

For anyone who wants the three riskiest areas checked fast.

$290

Report in 24 hours
  • API keys and secrets in the bundle
  • Row-level rules on every table
  • Cross-user data reads
  • Admin and hidden routes
  • Client-only permission checks

What you receive

All packages and prices. Every report includes a re-check after your fixes.

Questions about Cursor

cursor generated code security review

We review the generated code and test the running app: permission checks on every route, secrets handling, database rules, payment logic and error handling. Cursor's Bugbot reviews pull requests; an independent test adds a second account and a running attacker's view.

is code written by cursor secure

No editor can promise that. Studies on the evidence page found AI-written changes carried more security issues than human ones in the samples measured. The practical answer is to test the flows that move money or personal data before launch and to keep tests running in CI.

cursor security

Cursor documents Privacy Mode, sandboxed terminal run modes and .cursorignore. Two 2025 CVEs concerned prompt injection into the agent's tooling and were fixed in versions 1.3 and 1.3.9; keep Cursor updated and review MCP servers before approving them.