Cursor is safe to use as an editor, but the code it generates is not secure by default. Cursor optimizes for code that runs, so when an integration needs a key it tends to inline the value, and when it wires up an API route it often skips the authorization check that is not needed to make the feature work. The three issues we see most in Cursor projects are hardcoded secrets, .env files that get committed, and API routes with no server-side auth.
The risks that actually matter
Hardcoded API keys and connection strings
When a step needs a credential, Cursor frequently writes the literal value into the file so the code runs immediately. That key then ships to the repo and, if the value is used client-side, to the browser.
Committed .env files
Cursor may create a .env with real values and, without a matching .gitignore entry, it gets staged and pushed. A public push exposes every secret in it within minutes.
API routes without authorization
Generated route handlers commonly return or mutate data without checking who is calling. The UI hides the route, but anyone can call it directly.
How to secure a Cursor app
- Add a .cursor/rules or AGENTS.md rule forbidding inline secrets and requiring process.env.
- Confirm .env and .env.local are gitignored before your first commit.
- Add a server-side auth check to every API route that reads or changes data.
- Scan the project for hardcoded keys and missing auth before you deploy.