Guides

Cursor-built app security checklist (from a security engineer)

By Pritesh Ghodge, Senior Solutions Engineer (cybersecurity) · Last updated 8 November 2026

Cursor Agent can take you from a prompt to a Next.js (or Vite) app on Vercel with Supabase in an afternoon. What it can't know is what your data is supposed to be: which tables are public, which belong to one user, which keys can spend your money. Agent edits that "fix" an RLS error or move a key into NEXT_PUBLIC_ / VITE_ are a common way those mistakes land in production. Here is the checklist I'd run on a Cursor-built app before sharing it with real users.

1. Treat the published URL as the source of truth

Cursor works on your local project and git. Security for a stranger is whatever the deployed host serves. After every Agent change that touches env vars, auth, policies or API routes, open the published URL in a private window and re-check. The rest of this list is that outside view.

2. No secret keys in NEXT_PUBLIC_, VITE_ or client bundles

Anything with a NEXT_PUBLIC_ or VITE_ prefix is inlined into the JavaScript every visitor downloads. Fine for your site URL, analytics IDs and a Supabase publishable/anon key. Not fine for:

• the Supabase service_role or sb_secret_ key (it bypasses RLS completely),
• Stripe secret keys and webhook signing secrets,
• OpenAI, Anthropic, Resend or any other API key that costs money or sends mail as you,
• database connection strings.

Those belong in host Environment Variables without the public prefix, read only from Server Components, Server Actions, Route Handlers or a backend. If a key was ever in the browser bundle, rotate it at the provider. Removing it from the code doesn't un-leak it.

Quick check on your published site: open DevTools → Sources (or search the JS files) for sk_live, sk-, sb_secret_ and service_role. More detail: NEXT_PUBLIC_ and VITE_ variables are shipped to every visitor. If the key was a service_role: what to do in the next 15 minutes.

3. Every Supabase table has RLS on, and policies check whose row it is

Many Cursor apps wire up Supabase. The publishable key in the browser is fine; Row Level Security is what stops that key reading everything. Two traps:

• A table with RLS off is readable (and often writable) by anyone with the key.
• RLS on with a policy of using (true), or "any signed-in user", lets everyone (or every account) through. Private tables need (select auth.uid()) = user_id.
• Write policies with with check (true) let anyone insert or update rows that pass the USING clause — dangerous on user-owned tables when sign-up is open. See WITH CHECK (true).

The 60-second test (use your project URL and the publishable key from your app):

curl -s "https://YOUR-PROJECT.supabase.co/rest/v1/orders?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY" \
  -H "Authorization: Bearer YOUR_PUBLIC_KEY"

[] or a permission error is what you want for private tables. A row of real data means anyone can read that table. Full walkthrough: how to check if your Supabase tables are readable by anyone.

For write policies an outside scan can't test (open INSERT/UPDATE, with check (true), grants), use the free Supabase RLS policy checker: one read-only SQL query, paste the result, analysed in your browser.

A prompt you can paste into Cursor Agent:

List every RLS policy in my database as a table: table, command
(select/insert/update/delete), role, and the exact USING and WITH CHECK
conditions. Flag RLS off, using (true), with check (true), and any
user-owned table whose policies never mention auth.uid(). Propose
owner-only policies. Show me the SQL before applying it.

4. Storage buckets aren't accidentally public

Public buckets (or storage.objects policies that let anon list/upload) expose uploads the same way open tables expose rows. List buckets and policies in the Supabase dashboard or SQL, and try listing with the public key. Private buckets plus per-user folder policies and signed URLs are the usual fix. Guide: Is your Supabase storage bucket public?

5. Server Actions and Route Handlers are still public endpoints

Moving an OpenAI or Stripe call into a Server Action or Route Handler hides the key. It does not hide the endpoint. If it doesn't check who is calling, anyone can use it to spend your credits or do whatever the function does. For each one, ask:

• Does it require a signed-in user and verify the session, or is it deliberately public?
• Does it check the user is allowed to act on the record they passed in (not just that they're signed in)?
• Does it calculate prices on the server instead of trusting an amount from the browser?
• For payment webhooks: does it verify the provider's signature?
• Is there a limit on how often one user can call it, if each call costs you money?

More detail in AI API key exposed in your frontend.

6. Nothing extra is published with your site

Cursor Agent sometimes creates or edits .env, commits secrets, or leaves source maps on. From a browser, try /.env, /.git/HEAD and a .map next to one of your JS files on your published URL. You want a 404 or your app's normal page, not a file. Next.js doesn't emit production source maps unless you turn them on; check productionBrowserSourceMaps (and any Vite/webpack map settings) if you or the Agent changed them. See exposed .env, .git and source maps.

7. Security headers on your Vercel (or other) host

A Content-Security-Policy, HSTS and clickjacking protection (X-Frame-Options or CSP frame-ancestors) are set by your host config, not by Cursor. Check what your published site sends with curl -sI https://your-app.vercel.app (and again on any custom domain) and add the missing ones in vercel.json or next.config headers. Examples: security headers for vibe-coded apps.

8. The two-account ownership test

No checklist beats this. Sign up as user A and create some data. Sign up as user B in a private window. As B, try to open A's pages by changing IDs in the URL, and watch the network tab for requests that return A's rows. Then sign out and try again as a visitor with the public key (the curl above). Only test projects you own.

9. Re-scan after every deploy

Every Agent prompt can change a policy or add a public env var, including an AI "fix" for an error. After you ship, run the outside check again (or let Monitor re-scan on deploy). A green local build does not mean the live bundle and policies are still safe.

What an outside scan adds, and what it can't do

Cursor edits your project. An outside scan checks what the published site actually serves to a stranger: the built JavaScript, the files on the host, the headers, and what your public key can read. It can't see your business rules or test as a signed-in user, so it doesn't replace the two-account test or reading your policies. Using both catches different mistakes.

Abbi Labs' free quick check covers leaked keys in JS, Supabase tables anyone can read with the public key (limit=1), exposed .env/.git, and security headers. Full scans on a verified domain also cover public storage buckets and source maps. For write-side RLS holes, pair it with the free RLS policy checker.

Keep it that way

Abbi Labs scans your live app for leaked keys, Supabase tables readable with your public key, exposed .env/.git files and security headers. Monitor re-scans weekly and after deploys, and emails you only when something new appears.

Scan your app free

FAQ

Related guides

• v0 app security checklist (from a security engineer)
• Is my Bolt.new app secure? A security checklist before you publish
• Lovable app security checklist (from a security engineer)
• How to check if your Supabase tables are readable by anyone
• Supabase WITH CHECK (true): what that INSERT policy actually opens
• NEXT_PUBLIC_ and VITE_ variables are shipped to every visitor
• Supabase service_role key exposed? Do this in the next 15 minutes
• 3 files your production site shouldn't be serving: .env, .git and source maps
• Security headers for Lovable, Bolt, v0 and Cursor apps
• Free tool: Supabase RLS policy checker