Is my Cursor app secure?

Cursor is a code editor, so whether your app is secure depends on the stack you and Cursor's agent chose and how it's deployed; Cursor doesn't host your app or add a security layer to it. The usual gaps in AI-written apps are secret keys in client-side environment variables (NEXT_PUBLIC_, VITE_), database access rules left open (Supabase RLS, Firebase rules), and API routes that never check who's calling.

Run a free, read-only scan of your Cursor app to see where you stand. It takes a couple of minutes once you've proved you own the app.

How Cursor apps are usually built

There's no single Cursor stack. Common choices are Next.js or a Vite React app, with Supabase, Firebase or a Postgres database, hosted on a platform such as Vercel or Netlify.

That means the security model is your framework's and your database's. If the browser talks to Supabase or Firebase directly, access rules protect your data. If everything goes through your own API, that API's auth checks do.

Next.js inlines NEXT_PUBLIC_ variables into browser JavaScript and Vite does the same with VITE_ variables. Neither prefix should ever hold a secret.

Cursor's own security tools

Cursor's own security features are about the editor rather than your deployed app. Privacy Mode controls whether your code is used for training.

Cursor's docs say .cursorignore is not a security boundary: tools the agent runs (such as the terminal) can still read ignored files, so don't rely on it to keep .env contents away from the agent.

Bugbot, Cursor's AI pull-request reviewer, can be configured to flag security issues. It's a useful extra pair of eyes on code changes, not a test of what your live app exposes.

Common risks in Cursor apps

Secrets in public env variables

An agent that can't get a feature working may rename OPENAI_API_KEY to NEXT_PUBLIC_OPENAI_API_KEY so the browser can read it. That publishes the key. Keep the call on the server and rotate anything that was ever public.

API routes and server actions without auth

Route handlers and server actions are public endpoints that anyone can call directly, not just your UI. Each one needs to check the session and what that user is allowed to do.

Open database rules

With Supabase, every table needs Row Level Security and owner-based policies; with Firebase, rules must check request.auth.uid rather than allowing everything or any signed-in user.

The service role key in client code

Using the Supabase service_role key in a client component bypasses every policy. It belongs in server-only code, never in a NEXT_PUBLIC_ variable.

Committed secrets and exposed files

Keys committed to Git stay in its history. If .git or .env is served from your live site, or source maps are published, your code and keys are public. Rotate anything exposed.

What SealMyApp's scan checks

Searches your live JavaScript for secret keys (Stripe, OpenAI, Anthropic, AWS, Supabase service role, GitHub and more), including anything that came from a public env prefix.
If the browser talks to Supabase or Firebase, tests what an anonymous visitor can read: Supabase tables and storage, Firestore, Realtime Database and Firebase Storage listing.
Checks for exposed .env, .git, database dump and source-map files.
Probes common admin and API paths for responses that don't need a login, and reviews security headers and CORS.

We check from the outside, the way a stranger would, and never sign in, so problems that only show up for logged-in users (one user reading another's data, for example) aren't visible to us. A clean result means our checks found nothing, not that your app is guaranteed secure.

Quick checklist

No secret in any NEXT_PUBLIC_ or VITE_ variable.
Every route handler and server action checks the session and permissions.
Supabase: RLS on for every table with owner checks. Firebase: rules check request.auth.uid.
The Supabase service role key is only used in server code.
Git history scanned for secrets; anything found rotated.
No .env, .git or source maps on the live site.
Re-check after big agent edits.

FAQ

Does Cursor make my code secure?

No tool does that on its own. Cursor writes and edits code; whether the deployed app is secure depends on the code, your database rules and your hosting setup.

Does `.cursorignore` protect my secrets?

Not reliably. Cursor's docs say it isn't a security boundary, because tools the agent runs can still read ignored files. Keep real secrets out of the repo and in your host's secret settings.

Is a `NEXT_PUBLIC_` key safe?

Only if it's meant to be public, like a Supabase anon key, a Firebase web config or a Stripe publishable key. Anything else in a NEXT_PUBLIC_ variable is shipped to every visitor. Try our key checker.

Which Cursor apps can you scan?

Any web app with a public URL that you can prove you own, whatever stack or host it uses.

Go deeper

Sources

Cursor details were checked against the official docs on 2026-10-16. Builders change their products often, so check the current docs if something here doesn't match what you see.

One common security mistake in AI-built apps, how to fix it in your builder, and one useful tool. No spam; unsubscribe any time.