I scanned a bunch of Lovable apps and the Supabase RLS situation is rough

Discussion

Most of us came to Lovable because we wanted to ship without becoming backend engineers. That's the whole point. But here's the part that doesn't get said enough: Lovable wires your app to a real Supabase database, and the security on that connection is on you not on the AI.

The patterns I keep seeing:

  • Row Level Security off, or written backwards. There's literally a CVE for this (CVE-2025-48757) where Lovable apps had the auth logic inverted — logged-in users were blocked, while random visitors got full read access to everyone's data. 170+ live apps were affected, and these weren't obscure ones.
  • API keys in the frontend bundle. Supabase keys, sometimes OpenAI or Stripe keys, sitting in the JS that ships to every visitor. Anyone who opens DevTools can copy them.
  • Sensitive routes with no auth check, because "it worked when I tested it logged in."

Three things you can do right now, for free:

  1. Open your deployed app → F12 → Sources/Network → search the bundle for key, secret, sk_. If a real key is in there, rotate it.
  2. In Supabase, check every table has RLS enabled AND a policy that actually restricts by user. "Enabled with no policy" = locked down. "Disabled" = open to the world.
  3. Log out and try hitting your own data endpoints. If you can still see data logged out, so can everyone.

Full disclosure so I'm not "that guy": I got tired of doing this by hand, so I built a tool that takes a project zip and gives you back one fix-prompt you paste straight back into Lovable. It's paid per scan. But the 3 checks above catch the worst of it for free — do at least those before you share your app anywhere.

Happy to answer RLS questions in the comments, it trips up almost everyone.

Posted Jun 3, 2026, 11:55 AM UTC

615
Loading comments…