Technically speaking, is the "leak" or "vulnerability" in Loveable's architecture or in the Supabase database integration?
If the real issue is with Supabase then it needs further investigation as several AI tools use Supabase as standard now, not to mention many opensource projects.
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.
[−]reassess_blind · 2026-11-15 Sun 06:10 UTC ·
link
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.
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 the user doesn't have to worry and that Lovable will get Supabase access controls right.
If the real issue is with Supabase then it needs further investigation as several AI tools use Supabase as standard now, not to mention many opensource projects.
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.
There are many BAD databases, choosing the wrong one still makes the owner responsible.
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 the user doesn't have to worry and that Lovable will get Supabase access controls right.