Re:Lovable apps expose passport details and more than 200K p...
by dabbz on Sunday November 15, 2026 @01:05AM
(#50504412)
I think the idea is to use edge functions against the database with RLS helping with low level access control, but it's still a tough design pattern to hold people accountable to. May as well as write the whole thing in a backend and just skip Supabase's API/RLS entirely.
Re:Lovable apps expose passport details and more than 200K p...
by reassess_blind on Sunday November 15, 2026 @01:17AM
(#50504465)
The whole proposed benefit of their "query the database from the client" concept was the speed and ease of development. If you need edge functions (cost per invocation too, mind you) to make this happen, it's just a terrible design in general.
I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.
Re:Lovable apps expose passport details and more than 200K p...
by skeeter2020 on Sunday November 15, 2026 @10:05AM
(#50507427)
Have you looked at PocketBase? If I understand correctly it solves both of these to some degree and from my perspective pretty cleanly. Building a self-hosted, OS version of Firebase and SupaBase was the inspiration I believe.
In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.
Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.