I audited AI-built Supabase apps. These are the security bugs I keep finding

Larissa Dourado — Sun, 08 Nov 2026 21:05:04 +0000

Tools like Lovable, Bolt and Cursor can take you from idea to working app in a weekend. The demo works, the UI looks great, and you are ready to launch.

But "it works" and "it's safe to put real users on it" are not the same thing. I audit React + Supabase apps built with AI tools, and the same problems show up again and again. Here are the five that matter most, and how to check your own app in a few minutes.

1. Trusting IDs sent by the client

This is the most serious one. A server function receives something like notebook_id or order_id from the request, then reads or writes data with the service role key, which bypasses Row Level Security.

The function checks that the user is logged in, but not that the ID belongs to them. Any signed-in user can send someone else's ID and get their data.

Fix: before using an ID from the request, look it up with the caller's own session (so RLS applies), or check ownership explicitly.

2. Webhooks and callbacks that anyone can call

Payment webhooks and "job finished" callbacks often run without any secret check. Anyone who finds the URL can send fake payments or overwrite records.

Fix: verify the provider's signature, or require a long random token in the URL or a header.

3. RLS that is on, but not complete

RLS is enabled, but:

insert and update policies have no with check, so users can create rows for other users;
users can update their own profile, including the role column;
a view or a SECURITY DEFINER function quietly bypasses RLS.

Fix: read every policy, add with check, restrict updatable columns, and use security_invoker = true on views.

4. Data left in the browser

Persisted caches (React Query, Zustand, localStorage) keep customer data after logout. On a shared device, the next user sees it. And hard-coded seed data in src/ is shipped to every visitor, logged in or not.

Fix: clear caches on sign-out, and never put real data in the frontend source.

5. Mixing up public and secret keys

The Supabase anon / publishable key in your frontend is fine. It is designed to be public. The real problem is a service role key with a VITE_ prefix, or RLS that does not protect your tables.

The full checklist

I turned everything I check into a free checklist, with SQL queries you can run in the Supabase SQL editor:

👉 Lovable + Supabase Security Checklist

Only run these checks on apps you own or are authorized to test.

If you would rather have someone go through it for you, I offer audits and fixes for AI-built apps on Fiverr. Questions are welcome in the comments.