Budget an hour the first time you do this — that is an estimate, not a measurement, and a project with thirty tables will take longer than one with four. It is ordered by how much damage each item has actually caused, not by how hard it is.

1. Open the Security Advisor first. Supabase runs Splinter, its open-source Postgres linter, over your project and reports the results in the dashboard under Advisors, with alert emails to project owners. The "RLS disabled in public" finding is item one. This costs you nothing and finds the CVE-class problem immediately.

2. Enable RLS on every table in public. One line each: ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;. With RLS on and no policies, the table denies everything by default — your app may break. That is the correct starting state. Broken and closed beats working and open.

3. Read every policy, and distrust USING (true). This is the "insufficient" half of the CVE, and it is the half people miss. A table with RLS enabled and a permissive policy that returns true for everyone is exactly as exposed as a table with RLS off, but it shows up green in every dashboard. Each policy should scope rows to the caller — typically comparing an owner column against (select auth.uid()), wrapped in a subselect so Postgres evaluates it once per query rather than once per row.

4. Check the verbs. Policies apply per command. A single FOR ALL policy that you reasoned about as a read rule is also your write rule. Enumerate SELECT, INSERT, UPDATE and DELETE separately for every table that holds user data.

5. Attack it yourself, from outside the app. This is the only step that produces evidence rather than opinion. Take the anon key out of your own client bundle and hit the REST endpoint directly:

curl "https://<project-ref>.supabase.co/rest/v1/<table>?select=*" \
  -H "apikey: <your-anon-key>" \
  -H "Authorization: Bearer <your-anon-key>"

Both headers, as in Supabase's own REST documentation: the apikey header identifies the project, and the bearer token is what maps the request to the anon Postgres role your policies are written against.

If rows come back that a stranger should not see, you have reproduced the CVE in your own app. Do this for every table. Nothing in the UI can tell you this, because the UI is not where the request comes from.

6. Confirm no server-side key is in client code — or in history. Search the repository for service_role and any SUPABASE_SERVICE variable. The service role key bypasses RLS entirely by design. Then search the git history, not just the current tree: a key that was committed and later removed is still a leaked key.

7. Treat client-side auth checks as cosmetic. Hiding a button hides a button. If an agent implemented "only admins can do this" by conditionally rendering a component, that is a UI preference, not an authorization rule. The rule has to exist in the database policy or in a server-side function that verifies the caller's JWT rather than trusting a user_id sent in the request body.

8. Storage buckets are a separate system. Bucket policies are not table RLS and are not covered by fixing your tables. Check public-versus-private on every bucket that holds anything a user uploaded.

Look back at that list. Steps 1, 2, 3, 4 and 8 need a real database console you can log into and run SQL against. Steps 5, 6 and 7 need the actual source repository, including its history.

You cannot run this pass on a platform that gives you a hosted preview and a deploy button. Not "it is harder" — you literally cannot perform the audit, because the artifacts it inspects are not yours to open. That reframes what to look for in this category of tool: the useful question is not which generator writes the nicest React, it is whether it hands you the two things an audit needs.

Which leads somewhere uncomfortable, and with a condition attached that most write-ups skip. Lovable is the platform in the CVE at the top of this article, and it is also one of the few in its class where you can end up holding both artifacts: it maintains two-way Git sync with a GitHub repository you own — a repo that stays current as you iterate, rather than a one-time export — and it can sit on top of a Supabase project that is genuinely yours.

Read that "can" literally. New Lovable projects default to Lovable Cloud, a managed backend built on Supabase. Per Supabase's own troubleshooting documentation for exactly this confusion, a Lovable Cloud instance is provisioned and owned by Lovable: it does not appear in your Supabase dashboard and you cannot open it with your own Supabase credentials. On that default, steps 1 through 4 and step 8 are simply not available to you — no SQL editor of your own, no Security Advisor, no policy list to read. Connecting your own Supabase project instead is the thing that turns this checklist from reading material into something you can execute, and it is much easier to do before you have users than after.

And hold the platform itself at arm's length while you do. In April 2026 a second, platform-level flaw went public — reported by Matt Palmer, the same researcher behind the RLS disclosure, according to contemporaneous trade coverage. It was a broken-object-level-authorisation bug in Lovable's own API: reporting puts the HackerOne submission on 3 March 2026 and public disclosure on 20 April, and describes a free account being able to reach other users' project source code, database credentials and AI chat history, fixed for newer projects while projects created before November 2025 were said to remain exposed. That last detail is the sort of thing that changes; check its current status yourself rather than trusting the shelf life of this paragraph.

That is a genuinely mixed recommendation and it should be read as one. The claim is not that this platform is safe. It is narrower and, I think, more useful: owning your repository and owning your database is the only configuration in which the audit above is possible at all, and the April disclosure is the strongest available argument for owning them rather than trusting a vendor's control plane — including this vendor's.

Where Lovable is the wrong choice. Most importantly: anyone who is not going to actually run the pass. If you are going to generate an app that holds real user data and skip the RLS review, Lovable is wrong for you — and so is every other builder in this category, because they all have the same failure mode and most of them do not even let you look. The honest advice at that point is to hire someone.

It is wrong for anyone who intends to stay on the Lovable Cloud default, which is most people who never change it: that configuration is precisely the black box this article says you cannot audit, and picking the platform for its audit surface and then not claiming that surface gets you nothing. It is wrong for anyone whose threat model includes the vendor — if a platform-level API bug reaching your source code and database credentials is unacceptable to you, April 2026 is your answer and you should self-host from the start. It is wrong for anything regulated, or holding sensitive personal data, without a real security review by a person who does this for a living; this checklist is a floor, not an assessment, and it does not make you compliant with anything. It is wrong for integrating into a substantial existing codebase, where a generator that wants to own the whole repo fights you the entire way. It is wrong for bespoke backend logic that does not decompose into prompts. And it is wrong if credit-metered pricing annoys you, because audit-and-fix iterations are exactly the kind of unglamorous back-and-forth that burns credits without producing anything you can demo.

The slop paper's finding is that the cost of generation gets externalised onto a reviewer. When you build solo with an agent, there is no one to externalise it to, so the cost does not disappear — it just goes unpaid, and it sits in your database, and someone else eventually collects.

An hour with a curl command and a list of tables is the cheapest that debt will ever be.

---

Sources: arXiv 2603.27249 and 2604.16754 (Baltes, Cheong, Treude) for the AI-slop review-burden findings and quotes; Matt Palmer's public CVE-2025-48757 disclosure write-up (May 2025) and the CVE record — including its supplier dispute — for the Lovable/Supabase RLS incident; trade-press reporting from April 2026 for the subsequent broken-object-level-authorisation disclosure affecting Lovable's own API; Supabase's own documentation for Security Advisor, Splinter, REST headers, anon-key behaviour, and for how Lovable Cloud projects differ from a Supabase project you own. Vulnerability counts, patch status and platform defaults all change — re-check current guidance before relying on any figure or default described here.

Disclosure: Some links are affiliate links. We earn a small commission at no extra cost to you. This helps us create more comprehensive guides like this. Thank you for supporting independent tech content!