Supabase loves RLS, this is just poorly implemented RLS on the vibe-coder's side. It's too hard to reason about and not well exposed or debugged on Supabase's or Lovable's interfaces.

The core issue is how easy it is to misconfigure Supabase (much like Firebase) due to the data security relying on RLS policies. It's such a poorly designed system and so easy to get wrong, and it's clear here that Lovable's AI generator is getting it wrong.

Even when you do get Supabase's RLS policies correct, Supabase still doesn't offer a way to rate limit these tables. i.e Even if the data is secure, an attacker can overwhelm the database instance with big query in a simple for-loop and it's a constant source of issues in the Supabase Discord. There's no server in between that can enforce any rate limits. The whole "query the database from the client" has so many security pitfalls.

Funny I viewed Supabase as a professional company.

No, the core issue is Lovable exposes passport data. They chose Supabase and implemented it incorrectly.

There are many BAD databases, choosing the wrong one still makes the owner responsible.

It’s Lovable using Supabase incorrectly, so Lovable is rightly to blame.

To add some nuance: Supabase’s security controls aren’t the simplest to work with and have been a source of confusion -- and data exposure -- for years. But Lovable markets its product specifically to people who, it claims, don’t need that technical knowledge. That sets the expectation that Lovable will get Supabase access controls right.

This is exactly it.