What are Cursor security best practices?

The best practices specific to Cursor (not generic OWASP)

Every "security best practices" list tells you to use HTTPS and rotate keys. Those are table stakes. The list below is what actually matters for Cursor apps, based on the risks that appear in real Cursor deployments.

1. Review MCP server sources

*Why:* Malicious content in MCP tool responses can execute arbitrary commands. *Do this:* Review MCP server sources. Avoid untrusted MCP integrations. Watch for suspicious tool calls.

2. Enable Workspace Trust in settings

*Why:* Malicious .cursor/rules files execute when opening untrusted projects. *Do this:* Enable Workspace Trust in settings. Review .cursor/ files before opening projects.

3. Review all AI suggestions critically

*Why:* AI suggests vulnerable patterns: SQL injection, hardcoded secrets, weak auth. *Do this:* Review all AI suggestions critically. Run security scans on generated code.

4. Enable Privacy Mode

*Why:* Code sent to AI servers may expose proprietary logic or secrets. *Do this:* Enable Privacy Mode. Use .cursorignore for sensitive files.

5. Verify all package suggestions exist

*Why:* AI suggests non-existent packages that attackers could register. *Do this:* Verify all package suggestions exist. Check package reputation before installing.

Cursor-specific: audit every table for RLS before every deploy

The failure mode in Cursor + Supabase apps is always the same: a table gets added during a feature push, RLS never gets turned on, the full table becomes queryable via the anon key. Bake a pre-deploy check: `select tablename from pg_tables where schemaname = 'public' and not rowsecurity` — the result must be empty.

Verification

Even perfect best practices don't prove themselves — the only way to confirm the list above is implemented is to scan a deployed Cursor app. VAS probes each of secret detection, code security, database security, security headers by actually attempting the attack, not just reading headers or docs.