Security for the code you write with Cursor

"Cursor security" means two different things, and it pays to keep them apart. The first is securing your own Cursor setup: what leaves your machine, what the agent can run without asking you, and which servers and rules files you trust. The second is securing the code Cursor writes for you, which is what ends up deployed and exposed to the internet. This guide covers both, with a block of rules ready to paste into your project and a review prompt to run before every deploy.

Part 1: securing your Cursor setup

What leaves your machine

Cursor sends to its servers, and to the model provider's, the context it needs to answer: the open file, what it indexes from the project and whatever you paste into the chat. Turn on privacy mode in the settings if you do not want that code stored or used for training; on teams, enforce it from the plan. And remember that everything you paste into the chat travels: do not paste database dumps or credential files "so it understands".

Keep secrets out of the index

Cursor indexes the project to give the model context. A .env, a service-account.json or a folder of certificates should not be part of that index. Create a .cursorignore file at the root with the patterns to exclude; it follows .gitignore syntax:

.env
.env.*
*.pem
*.key
**/service-account*.json
secrets/

If something sensitive was already indexed, remove it from the index in the settings and, if it was a real key, rotate it.

Auto-running commands

Cursor's agent can run terminal commands on its own if you let it. It is convenient and it is dangerous: a misunderstood prompt, or malicious text the agent reads from a file or a web page, can end in an rm -rf, a git push --force or a curl | sh. Keep manual confirmation for commands that delete, publish or install, use the allow list only for harmless things (tests, lint, build) and never give the agent production credentials in its environment.

Third-party MCP servers

MCP servers extend what the agent can do: read your database, call APIs, drive the browser. Each one is code running with your permissions, and the model reads its tool descriptions as instructions. Install only servers from sources you know, review what they ask for, prefer the ones that work with read-only credentials and watch for configuration changes: a server that changes its definition after you approved it is a red flag.

Rules files from other people's repos

Rules files (.cursor/rules, .cursorrules) are instructions the model obeys on every request. If you clone a repository, a template or an example from the internet, it may carry rules you do not see at a glance, even with invisible characters hiding instructions to slip in malicious code. Open and read the rules files of any project you did not write before letting the agent work on it.

Keep Cursor updated

Like any editor with an agent inside, Cursor has had security flaws of its own, several around workspace trust and MCP. Update when a new version ships and do not open projects of doubtful origin with auto-run enabled.

Part 2: the flaws Cursor puts into your code

The model optimises for the code to work, not for it to be secure. These are the patterns that repeat most in apps written with Cursor and how to spot them:

• Hardcoded secrets. To get an example running fast, the key ends up in the code or in a public variable. Search your bundle for sk_live, service_role, AKIA and -----BEGIN. More in the secrets your app leaks in the browser.
• Open CORS and auth disabled "to make it work". Faced with an error, the typical suggestion is to reflect any origin or skip the session check. It works in the moment and leaves the door open in production.
• Endpoints that trust the client. Routes that accept the user_id, the role or the price from the request body without checking it on the server.
• No security headers. Generated code almost never adds CSP, HSTS or X-Frame-Options; check with the headers checker.
• Old dependencies. The model proposes the versions it knows, not the latest. Run npm audit before deploying.

A block of security rules for your project

The most profitable thing you can do is tell the model, once and for all, what it must not do. Paste this into .cursor/rules/security.mdc (or into .cursorrules) with the rule set to always apply:

# Security rules (always apply)
- Never hardcode API keys, tokens or passwords. Read them from
  environment variables on the server only.
- Never put secrets in variables prefixed NEXT_PUBLIC_, VITE_ or NUXT_PUBLIC_.
- Never disable authentication, authorization or Row Level Security
  to make something work. Fix the policy instead and explain why.
- CORS: allow only an explicit list of origins. Never reflect the
  request origin together with credentials.
- Validate input and authorize every API route on the server, even if
  the UI hides the action.
- Set security headers: CSP, HSTS, X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy.
- Session cookies must be Secure, HttpOnly and SameSite=Lax.
- Add a dependency only when necessary, pinned to a maintained version.
- If a request conflicts with these rules, stop and explain the
  security trade-off before writing code.

A review prompt before you deploy

Before each deploy, open a fresh chat with the whole project in context and ask: "Review this project as a security auditor before deployment. List every secret that reaches client code, every API route without a session or permission check, every relaxed CORS or RLS rule, the missing security headers and the cookies without Secure, HttpOnly or SameSite. For each finding give the file, the line and the fix. Do not change code yet." Then fix the findings one by one and ask for the review again.

Check the result from the outside

The model reviews the code it sees; what matters is what an attacker sees. When you deploy, run Scanaris on the public URL: it detects secrets in the JavaScript, permissive CORS, misconfigured headers and cookies, reachable sensitive files and versions with known vulnerabilities, and gives you a prompt to paste into Cursor for each finding. Leave it on monitoring and it warns you when a vibe coding session reopens something that was already closed. For the full map, read the security guide for AI-built apps and the launch checklist.

Frequently asked questions

Is it safe to use Cursor with company code?

With privacy mode on, secrets excluded from the index and no real data pasted into the chat, the risk is comparable to any cloud tool. Check your company's policies and, if needed, use the team plan to enforce the configuration.

Is the code Cursor writes less secure than hand-written code?

Not necessarily, but it fails in predictable places: secrets, permissions that get in the way and configuration nobody asked for. With clear rules and a review before deploying, the result is usually better than average.

What do I do if the agent already ran something it should not have?

Rotate any credential it had access to, review the git and terminal history to see what it touched, and restrict auto-run before continuing.