If you are asking “is my Cursor app secure?” the honest answer is that you have two things to check, not one: the app the agent wrote, and Cursor itself on your machine. Cursor is different from tools like Lovable or v0 in a way that matters here. It does not build apps from a fixed template. It ships no default database, no default login system, no default framework. Whatever your project already contained, plus whatever the model chose to write that session, is your stack. So nobody can tell you what to fix without opening your repo. And because Cursor runs on your own computer with your own files, shell and keys, a real share of the risk is not in the app at all: one configuration file in your project can hand out working passwords to your live database. Below is what to check, in order, in an afternoon.
First, find out what you actually built
Read your project’s dependency manifest — package.json for a JavaScript or TypeScript project, pyproject.toml or requirements.txt for Python, Gemfile or go.mod for the rest. That tells you the framework, and everything else in this article depends on it. There are combinations people commonly end up with in this ecosystem, but they are conventions rather than anything Cursor guarantees, so do not assume — read the file. Hosting, databases and payments all arrive the same way: as opt-in plugins from Cursor’s marketplace (Vercel, AWS and Cloudflare for deploys; Supabase, Neon and Stripe among the rest), none of which is installed unless you asked for it. There is no default deploy target either.
The app check: can one customer read another customer’s data?
This is among the most common real problems in an AI-built app, and in Cursor it has a specific shape. Nothing is enforcing access rules underneath by default. Unless you added a database that does it — Supabase row-level security, say — the check that stops person A from opening person B’s invoice lives only in the code the agent wrote for your own API, and only if it wrote it.
Test it by hand. Sign up twice, with two different email addresses, in two different browsers. Create something in account A — an order, a note, a project. Copy the address of that page or the address your app calls to load it. Now paste it into account B’s browser and change the number or ID in it. If account B sees account A’s data, that is the bug. It is also the hardest one to walk back, because afterwards you cannot tell whether anyone used it. Do it for every screen that shows something private, and for delete and edit, not just view.
Your .env file is probably less private than you think
A .env file is where your keys and passwords live in plain text. Cursor’s documentation lists .env* in a default ignore list, which sounds like the agent cannot see them. Cursor’s own pages do not agree with each other on this. A staff reply on Cursor’s forum in February 2026 said that list “only applies to indexing” and “does not affect Agent tool calls (Read file) or tab completion”, while the help pages describe ignored files as blocked from the agent. Behaviour also changes between versions, so treat this as something to verify on your own machine rather than assume in either direction.
Two practical steps. Add a file called .cursorignore at the root of your repo listing .env*, *.pem and any secrets folder; that file is documented as blocking Agent, Tab and Inline Edit, not just indexing. Then accept the limit Cursor states plainly in the same docs: terminal commands and MCP server tools run outside those file access controls, so an agent that runs a command to print your .env can still see it. Because of that, rotate — generate new ones and delete the old — any key that has sat on disk during agent sessions and protects something expensive: your database, your payment account, your email sender, your cloud bill. Also run git log --all --diff-filter=A --name-only -- '*.env*' to see whether a secrets file was ever committed. If it was, deleting it now does not help. Rotate.
The file that leaks your production database
If you connected Cursor to Supabase, Stripe, AWS or similar, the connection settings live in .cursor/mcp.json inside your project, and plenty of setup guides show you pasting the key straight into it. Unless you deliberately ignored that path, it is committed with everything else. Run git ls-files | grep '^\.cursor/'. If mcp.json or environment.json comes back, open them and look for actual key material rather than references like ${env:MY_KEY}, which Cursor supports for exactly this reason. Check history too, with git log -p -- .cursor/mcp.json. Then check what those keys can do: anything the agent can reach should be a read-only or test credential, never the full-power key for your live database. Note that .cursor/environment.json has no field for secrets at all and is meant to be committed as plain text, so nothing sensitive belongs in it.
Two settings inside Cursor
Check your run mode, under Cursor Settings > Agents > Approvals & Execution. There are three. Auto-review, the default since version 3.6 in May 2026, puts every shell, MCP and fetch call through the same order: anything on your allowlist runs immediately, anything that can be sandboxed runs there with its filesystem restricted and its network limited to an allowlist, and everything else goes to a small classifier model that decides whether to allow it, try another approach, or ask you. Allowlist mode is stricter. “Run Everything” drops both the classifier and the sandbox. Cursor is blunt about the ceiling here — its docs say “Auto-review is not a security boundary”, because the classifier can allow a call you would have blocked. So also check what you added to the allowlist over time, since a broad entry like “any npm command” is a hole in an otherwise sensible setting. One important caveat: that sandbox is built on macOS and Linux operating system features. On Windows there is no sandbox, so a Windows machine on the same settings is not protected the same way. Separately, make sure your Cursor is version 3.0 or later — that release, in April 2026, fixed a pair of flaws (nicknamed DuneSlide, both rated 9.8 out of 10) where a malicious web page or tool response could steer the agent into overwriting the helper that enforces its own sandbox, and then run commands on the developer’s machine.
If you use cloud agents, Cursor’s own docs say they have internet access by default and warn that this brings a data exfiltration risk — a prompt injection tricking the agent into uploading your code to a malicious site. Switch the network mode to an allowlist, and store credentials in the Secrets tab as Runtime or Build secrets rather than the plain environment variable type, which the agent can read. Cursor notes Runtime Secrets are redacted from the agent but still visible to anyone using that agent’s terminal.
A text file in your repo can rewrite what the agent does
Cursor automatically reads instruction files in your project: .cursor/rules, AGENTS.md, and the legacy .cursorrules, which still works but is being retired. Security researchers at Pillar demonstrated in March 2025, against Cursor and GitHub Copilot, that instructions can be hidden in a rules file using invisible characters — zero-width joiners, bidirectional markers — so they do not show up in your editor or in a pull request review, but the model still follows them. In their demonstration the agent added an attacker’s script to generated code and was instructed to say nothing about it. Cursor’s position at the time was that this is the user’s risk to manage rather than a platform bug, which is another way of saying nothing will catch it for you. Nothing about the technique is specific to the rules format, so treat every instruction file the agent reads the same way. This matters if you cloned a starter repo or copied a popular rules pack. Look for hidden characters with grep -rIPn '[^\x00-\x7F]' .cursor AGENTS.md .cursorrules — macOS ships a grep without -P, so use rg -n '[^\x00-\x7F]' there — and read anything that comes back, since ordinary accents and em dashes match too. From now on, review changes to those files as carefully as you review code, because that is what they are.
Work through those five in order and you have covered the things that actually cause damage after launch. If you want the wider list that applies to any app regardless of which tool built it, the pre-launch checklist covers billing, email, backups and the rest. And if you also built something in Lovable, the risks there are genuinely different — see is my Lovable app secure.
npx launchprep covers the part of this that lives in your files — a committed .env, keys left in git history, a server secret that reaches the browser bundle. It cannot read your Cursor settings and it cannot run the two-account test for you. The free tier is unlimited and runs on your machine.
Questions people ask
Can I just ask Cursor whether my app is secure? You can, and it is a reasonable starting point, but treat the answer as a list to verify rather than a verdict. It is reviewing code it wrote itself, much of your deployed configuration is somewhere it cannot see unless you installed a plugin that reaches it, and it will sound equally confident whether it checked properly or not. The two-account test above tells you more than any answer in the chat window.
I never committed my .env file. Am I fine? Not automatically. Committing is only one of the ways a key gets out. If the agent read the file during a session, that content went to the model as part of the conversation, and if you ever pasted a key into chat to debug something, same thing. Run the git history command above, and rotate the keys that guard anything costly regardless of what it says.
Do I have to fix all of this before I launch? No, but do them in this order. One, the two-account data test, because that is the one that hurts real customers. Two, get keys out of committed config files and out of anything that ships to the browser. Three, rotate the important ones. The editor run modes can wait a week — they mostly protect you and your machine. The rules files are not in that category: a poisoned rules file writes code that ships to your users, so read those now.