Is my Cursor app secure? A pre-launch checklist for apps built with Cursor

Short answer: not automatically. Cursor is a code editor with an AI agent, so your app is exactly as secure as the code, keys and database settings it ends up with. Cursor gives you good tools for the code side. Once the app is live, every visitor can read what it sends to the browser, so check that side too.

1. Keep secrets out of the agent's reach and out of git

Cursor ignores .env* files and everything in your .gitignore by default, and a .cursorignore file can block more paths from Agent, Tab, Inline Edit and @ mentions. Cursor's ignore-file docs also say two things worth knowing: the terminal and MCP tools the Agent uses can't be blocked by .cursorignore, and complete protection isn't guaranteed.

How to check: make sure .env and .env.* are in .gitignore, then run git log --all -- .env to see whether one was ever committed. If a real key was committed or pasted into a chat, revoke it at the provider and make a new one. Deleting it from the code isn't enough.

2. Keep secret keys out of NEXT_PUBLIC_ and VITE_ variables

Many Cursor projects use Next.js or Vite. Next.js puts every variable that starts with NEXT_PUBLIC_ into the browser bundle, and Vite does the same with VITE_. That's fine for public values like a Supabase project URL, a Supabase anon or sb_publishable_ key, or a Stripe pk_live_ key. It is never fine for a Supabase service_role or sb_secret_ key, a Stripe sk_live_ key or an OpenAI sk- key. Calls that need a secret belong in server code (an API route, server action or Edge Function).

How to check: open your deployed site, open DevTools → Sources and press Ctrl+Shift+F (Cmd+Option+F on Mac). Search for service_role, sb_secret_, sk_live_, sk- and PRIVATE KEY. Our guide to finding exposed API keys on your website has the full list of patterns.

3. Check Row Level Security if you use Supabase

If your frontend talks to Supabase with the public anon key, Row Level Security policies are what keep strangers out of your data. Every table in an exposed schema needs RLS on, and each policy should be tied to the user (for example auth.uid() = user_id) unless the data really is public. A policy that says using (true) lets everyone read every row.

How to check: run Supabase's Security Advisor, then test with two accounts: user A should never see or change user B's rows. Our Supabase RLS checker guide has the SQL and a signed-out test.

4. Review what the agent changed before you merge

Read the diff for anything that touches sign-in, payments or data access. Cursor's Bugbot reviews pull requests and flags bugs and security issues, and it can be run on every PR update. It is a strong code-side check. It looks at your code changes, so pair it with an outside check of the deployed site.

5. Make sure protected pages are protected on the server

Hiding a button or redirecting in the browser doesn't protect anything. Admin-only data and actions need a server-side check or a database policy. Open your app signed out in a private window and try links that should need a login, then sign in as a normal user and change an ID in a URL to someone else's record. You should be refused both times.

6. Check what your live site exposes

• Public /.env or /.git/config files (you should get a 404 or your normal page, never file contents)
• A public JavaScript source map, which can hand out your original code
• Missing security headers, cookies without Secure, HttpOnly or SameSite, and HTTP that doesn't redirect to HTTPS
• Loose CORS settings, missing SPF or DMARC email records, and Supabase tables or Firebase data anonymous visitors can read

A free SniffPup scan checks all of these at once, passively: no logins, no attack payloads, and it never uses a secret key it finds.

How the tools compare

Facts checked Oct 21, 2026 on each tool's own pages. Each one does something well, and they work best together.

• Cursor Bugbot sees your code changes in every pull request, which no outside scanner can. SniffPup adds the other side: what your deployed site actually serves to a stranger.
• ScanVibe gives full results and fix instructions for every finding on its free plan, which is generous. SniffPup's free scan lists every issue plus a full fix free for every critical issue, keeps the last 20 scans per app on every plan, and writes fix prompts for Lovable, Cursor, Bolt and Claude Code.
• SafeToShip has a free quick scan (its pricing page lists unlimited quick scans; its FAQ says free users get 1 scan per month), a $9 one-scan full report (the same price as our $9 Full Fix Report) and a deep scan that includes your code. SniffPup's $9 report adds 30 days of re-scans and a free first month of Solo upon opt-in, and Solo monitoring is $7/mo with weekly re-scans and email alerts, compared with SafeToShip Pro at $24/mo.

See the full side-by-side on how SniffPup compares and exactly what the scanner does.

Building with Bolt too? Here is our Bolt app security check.

Deployed already? Run a free Cursor app security scan on your live site.

FAQ

A clean report is not a guarantee of security. Only scan sites you own.

Run a free scan →