CURSOR SECURITY CHECKLIST

Cursor is an editor, not a hosted platform — which means the security risks are not in Cursor itself, they are in what Cursor writes into your repo. Two patterns matter most: agent mode silently rewrites code far from the diff you are reviewing (so a “fix this typo” prompt deletes a CSRF check), and the .cursorrules / .cursor/ files end up in chat context, where secrets pasted “just to test” leak into provider transcripts. The checklist below is what we look for first when we audit a Cursor-heavy repo.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup you do once Cursor is part of your team’s regular flow.

How to use this checklist

Walk it once on a representative branch, then make it part of your PR template. The Cursor-specific items don’t show up in normal code review because reviewers focus on the intentional diff — the dangerous changes are the ones the author didn’t realize they made.

Critical (fix before launch)

1. Audit Cursor-generated SQL for parameterization

Why it matters. Agent mode commonly emits string-concatenated queries when it can’t infer the ORM in use, especially in Python and Node scripts that don’t use Drizzle/Prisma/SQLAlchemy. The result is a textbook SQL injection in production code that “works” against the test fixtures.

How to check. Search the codebase for f"SELECT, f"INSERT, `SELECT ${, + user_id +, and format("SELECT. Any match is a potential injection.

How to fix. Replace with parameterized queries — ? placeholders for SQLite, $1 for Postgres, named bindings for ORMs. Reject the Cursor suggestion that “fixes” the warning by escaping quotes manually.

2. Review every generated auth middleware before merging

Why it matters. Cursor will sometimes scaffold an Express/Fastify/Next.js middleware that reads the session but does not actually reject the request when the session is missing. The route returns 200 with empty data, which looks like “logged out user, no data to show” — but signs and exposes the shape of the response, including admin fields.

How to check. Open every file with middleware, requireAuth, withAuth, getSession, or requireUser in the name. Each one must call return res.status(401).end() (or equivalent) on the negative path, not just next().

How to fix. Add a unit test per middleware that calls the route with no auth header and asserts a 401. Without the test, the regression comes back the next time Cursor refactors the file.

3. Strip API keys from .cursorrules and .cursor/ files

Why it matters. .cursorrules and .cursor/rules.md are sent to the model provider on every prompt. Developers paste API keys into these files “as a working example” and forget. The keys then sit in provider transcripts, in your repo, and often in your .git history.

How to check. Read every file under .cursor/. Run git log -p -- .cursorrules .cursor/ and search the output for sk_, sk-proj-, eyJ, and password.

How to fix. Remove the keys, rotate them, and add .cursor/secrets/ (or similar) to .gitignore if you must keep working notes. Use placeholders (<YOUR_KEY>) in rules files.

4. Verify Cursor did not silently weaken existing security middleware

Why it matters. This is the failure mode that actually puts apps in the news. You ask Cursor to “make this endpoint faster”. It removes a CSRF check “because the test passes without it”. Or you ask it to “support JSON bodies” on a route that was form-only, and the new handler skips the CSRF check that lived on the form path.

How to check. On every PR, diff the security-sensitive files against main: middleware, auth utilities, CORS config, CSP headers, JWT verification, RLS policies, Firebase rules. Any deletion or relaxation in those files is suspect.

How to fix. Add CODEOWNERS entries for security-sensitive files so they require human review. Add CI checks that fail when specific lines (csrf(), requireAuth(, verifyJwt() are removed.

5. Check generated upload handlers validate MIME and size

Why it matters. Cursor’s first-pass file-upload endpoint usually trusts whatever the browser sent — no size cap, no MIME allowlist, no path traversal protection on the saved filename. This is how you end up serving someone else’s PHP from your S3 bucket.

How to check. For every upload route, confirm: (a) multer/busboy/formidable is configured with limits.fileSize; (b) the saved filename is regenerated server-side, not taken from the upload; (c) there is a MIME check against an allowlist (not a denylist).

How to fix. Hardcode the size cap, regenerate filenames as UUIDs, and validate MIME both by header and by file-content sniff.

6. Confirm Cursor did not commit anything you didn’t approve

Why it matters. Auto-run mode (especially with the YOLO --dangerously-skip-permissions equivalent setting) will run git commit and even git push without prompting. We have audited repos where Cursor pushed half-finished migrations to main. The damage isn’t the bad code — it’s that production deployed before anyone noticed.

How to check. git log --author="cursor" and review every commit. Confirm branch protection on main requires PR review.

How to fix. Disable auto-commit in Cursor settings unless you’re working on a throwaway branch. Branch protection on main is non-negotiable.

High (fix in the first week)

7. Enforce code review on Cursor-authored PRs

If your team uses Cursor heavily, it is no longer “code I wrote and reviewed myself” — it’s code an LLM wrote and a human glanced at. Require a second human reviewer on every Cursor-authored PR, especially if the PR touches authn/authz, payments, or anything with PII.

8. Re-run dependency audit after Cursor adds packages

Cursor cheerfully adds dependencies to solve small problems (I'll just install lodash for this one util). Run npm audit / pip-audit after every session. Ban transitive dependencies you don’t recognize during PR review.

9. Disable .cursorignore bypass for files with secrets

.cursorignore keeps files out of model context, but the agent can still read them via the file system if your settings allow it. Move secrets out of the repo entirely (env vars, secret manager) rather than relying on ignore files to hide them.

10. Pin the Cursor model version on production-adjacent repos

Cursor lets you switch models per chat. Different models have different failure modes (some default to insecure SQL, others to insecure deserialization). Pin a specific model in the repo’s .cursor/settings.json so reviewers know what generated the diff.

11. Disable telemetry on repos with sensitive code

Cursor sends prompts to model providers (OpenAI, Anthropic) and to its own telemetry. For repos containing customer PII, healthcare data, or unreleased IP, switch to “Privacy Mode” in Cursor settings and confirm the indicator shows “no data retained.”

12. Verify Cursor did not regenerate test fixtures with real data

Cursor will sometimes “improve” a test by replacing dummy data with what looks like real-world examples — including production-shaped emails, names, and addresses. If the source for that data was a fixture file or a database dump in your local env, you may now have real PII in your test suite.

Medium (fix when you can)

13. Use plan mode on unfamiliar codebases

Before letting Cursor edit a codebase you don’t know well, ask it for a plan. Reading the plan catches “I’ll just turn off this middleware to make the test pass” before it happens.

14. Document which files Cursor is allowed to edit

Add a .cursor/rules.md that explicitly forbids Cursor from touching infra/, migrations/, .github/workflows/, and auth/ without confirmation. Cursor follows these rules most of the time.

15. Add pre-commit hooks that block staged secrets

pre-commit with detect-secrets or gitleaks catches keys Cursor pasted into config files or test fixtures before they reach the remote.

16. Audit the .cursor/chat-history for sensitive data

Long chat sessions accumulate paste-bin worth of code, including secrets, customer data, and internal URLs. The history is local but it’s also synced if you enable cloud sync. Periodically clear it.

17. Lock down CODEOWNERS to require human review on infra paths

CODEOWNERS pointing infra and security directories at a human team forces a human approval on Cursor-authored changes there, regardless of who clicked merge.

18. Add CI gates that flag dangerous patterns

CI rules that fail on eval(, exec(, dangerouslySetInnerHTML, cors(), and os.system( catch Cursor regressions that pass review because nobody noticed the new line.

After every Cursor session

• git diff the whole branch — not just the file you were focused on. Cursor edits adjacent files when it thinks they’re related.
• Search the diff for cors(), requireAuth, csrf, verifyJwt, sanitize. Any deletion is suspect.
• Run the test suite, then run the security tests separately if you have them — Cursor sometimes “fixes” failing security tests by changing the assertion.
• Audit package.json / requirements.txt / go.mod for new dependencies.
• Check .cursor/ for newly added files.

Common attack patterns we see in Cursor projects

The middleware that returns 200. Auth middleware reads the session, finds none, calls next() anyway. Route returns 200 with {user: null, items: []}. Looks fine in dev, exposes admin endpoint shape in prod.

The string-concatenated WHERE clause. Internal admin script Cursor wrote to “quickly query users” hardcodes f"SELECT * FROM users WHERE email = '{email}'". Three months later it gets repurposed into an HTTP endpoint and ships to prod.

The deleted CSRF token. “Make the form submit faster” prompt removes the CSRF middleware “because it was causing the failing test”. Test was failing because of an unrelated typo; CSRF is now off in production.

The leaked rules file. .cursorrules contains My OpenAI key is sk-proj-.... Repo is public. GitHub search finds it within hours.

Related Resources

How to Secure Cursor

Step-by-step guide for hardening a Cursor workflow — settings, rules files, CODEOWNERS patterns, and CI gates that catch the most common regressions.

Is Cursor Safe?

In-depth analysis of the editor’s privacy and security model — what data leaves your machine, where it goes, and what the practical failure modes are.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through the deployed result of your Cursor work, attempts the SQL injection and missing-auth attacks above, and reports what got through — with file and line numbers to fix.