Is Cursor safe?

Is Cursor-generated code safe to ship?

Cursor is not tied to one backend, it writes code against whatever you point it at. That flexibility is the appeal, and it is also why the gap looks a little different than the Supabase-specific one you will see on other builders.

Run the 60-second self-check →Or run the free Leak Check
Credit where it's due

What Cursor actually does well

Understands your existing codebase and writes changes that fit the patterns already there.

Works with any stack, Supabase, a custom Node API, Postgres, whatever you already chose.

Handles large, multi-file refactors and new features without losing context.

The gap

The gap: auth checks that live only in the UI

Because Cursor writes to your existing architecture rather than scaffolding its own, the most common failure is subtler than a missing database policy: an auth check that hides a button or a page in the React component, with no matching check in the API route or server function underneath it. The route itself is still reachable by anyone who knows the URL or reads it out of the JS bundle. The same pattern shows up with hardcoded keys, a developer asks Cursor to "get this working," Cursor puts a key directly in a client component or a NEXT_PUBLIC_ prefixed variable, and it ships to the browser.

60-second self-check

Check Cursor for this yourself right now

This one is manual since there is no single backend to point a scanner at, but it takes about 60 seconds.

  1. 01

    Find a page or feature in your app that is supposed to require login, for example an admin or account settings page.

  2. 02

    Open an incognito or private browser window with no session, and navigate directly to that page's URL.

  3. 03

    If the page or its data loads without redirecting you to a login screen, the check is happening client-side only.

  4. 04

    Separately, open devtools Sources tab on your live app and search the bundle for "sk_", "AKIA", or "service_role" to catch any hardcoded secret.

Rather not do this by hand? The free Leak Check runs the anon-key probe and a client bundle scan against your live URL and gives you results in under a minute.

Run the free Leak Check →

Where the numbers come from

We scanned 66 live apps built with Lovable, Bolt, Cursor, base44, and Tempo. 41% of the Supabase-backed apps had at least one table anyone could read with the public anon key. The full methodology and findings are in the data report.

Read the data report →
FAQ

Common questions about Cursor security

Both, in practice. Cursor writes correct code for the instruction it is given. If the instruction is "add an admin page" without specifying "and reject the request server-side if the caller is not an admin," Cursor will often produce a page that looks protected but is not enforced at the API layer.
Add the same check inside the API route, server action, or Edge Function that the page calls, not just the component that renders it. The rule of thumb: if a request can be made directly with curl and still succeed, the UI check was not enough.
Yes, and it stacks with the RLS gap covered on our other builder pages. Even a page-level auth check does not stop a table-level read if RLS is not enabled, the two need to be fixed independently.
Good. Still worth testing every route that should require login the same way, and worth running the free Leak Check for a second pass against the live bundle.
Any time a new protected route or admin feature ships. It is a five-minute habit that catches the single most common gap in AI-assisted code before a user finds it first.
Check another builder

Is your builder safe?

Is Lovable safe? →Is Bolt safe? →Is Replit safe? →Is v0 safe? →Is base44 safe? →