Is the app Cursor built secure?

Cursor is a code editor built on VS Code with an AI agent that can edit files and run terminal commands. The editor side carries the same risks as any editor with extensions. The agent side adds two more: commands it runs on your machine, and files it reads and sends to the model as context.

• Keep terminal commands on ask rather than auto-run, or restrict auto-run to commands you trust.
• Add a .cursorignore file listing .env, key files and anything else the agent should not read.
• Be careful with MCP servers and with pasting in content from untrusted pages or issues. Text in them can steer the agent.

Cursor does not deploy your app. You ship it to Vercel, Netlify, a VPS or somewhere else, so the risks depend on your stack. These come up again and again in agent-written projects:

• A secret key in a NEXT_PUBLIC_ or VITE_ variable, added when client code could not read a server variable.
• An API key hardcoded in a React component while prototyping and never moved.
• A .env file committed because .gitignore was missing, or copied into a public folder.
• A server with no security headers, since nothing in the prompt asked for them.
• CORS opened up to any origin with credentials to fix a development error.
• On a VPS: the whole project folder served by nginx, including .git and .env.

Cursor supports project rules, stored in .cursor/rules, that are added to the agent's context. A short security rule saves you fixing the same mistake twice:

Security rules for this project:
- Secret keys are only read on the server from process.env. Never prefix them with NEXT_PUBLIC_ or VITE_.
- Never hardcode keys in source files.
- .env files stay out of git and out of public/ and the build output.
- Every API route that returns user data checks the session first.
- CORS allows only our own origin.

Audit this project for security before deploy. Find any secret key that could reach the browser, including hardcoded keys and NEXT_PUBLIC_ or VITE_ variables, and move each call into a server route. Check .gitignore covers every .env file. Add security headers for our host (HSTS, a Content-Security-Policy that fits this app, X-Frame-Options, X-Content-Type-Options, Referrer-Policy). Make session cookies Secure and HttpOnly. List the changes before applying them.

• Vercel or Next.js: headers in next.config.ts or vercel.json, secrets in project environment variables without NEXT_PUBLIC_.
• Netlify: a _headers file in the publish folder, secrets in site environment variables used by Netlify Functions.
• Express on any server: the helmet package or res.setHeader calls, secrets in the server environment.
• nginx on a VPS: add_header lines, a root that points at the build folder, and a rule that denies dotfiles.

location ~ /\. {
    deny all;
}

1. Add .cursorignore and a security rule file before the agent writes much code.
2. Before deploying, search for sk_live_, sk-, AKIA, ghp_ and BEGIN PRIVATE KEY in src and in the build output.
3. Run git log --all -- .env to confirm no env file was committed. Rotate anything that was.
4. Set headers for your host and redeploy.
5. Scan the live URL.

An outside scan checks what your deployed site exposes: secret keys in the HTML and your own JavaScript bundles, public .env and .git files, security headers, the https redirect, cookie flags and CORS. It can identify common hosts and frameworks, so fixes come in the right config format. It does not read your repository, log in, or test your API's access rules, so review those in code.