This is why any DB connections should be "air-gapped" with an API. I use PG on a side project and I don't have RLS enabled but as the time time, a user cannot get/set anything in the DB unless it goes through an API endpoint and the endpoint + middleware ensures that a user has access to whatever they are modifying / reading.
I think Supabase just have bad defaults... Especially for non technical people that they market to.
I think by default they have some sort of public schema which is the default schema and for which PostgREST is enabled. There may be a checkbox to change that during setup but it's not checked by default.
Instead, one should probably use a different schema for the actual tables and create views that define the public API in the public schema.
I am not sure but isn't this something the industry is at a risk of moving from with react frontend engineers insisting on server functions sprinkled in the client code?
Just asking, because it sounded funky when I heard it at first.
Server Functions don't expose ability to query DB from the client (unless that is specifically what you're trying to do). You can think of them as "syntax for endpoints". They don't change which code runs where.
They still execute on the server. Server and client code is never mixed in the same file, and there is a way to enforce at the build time that code destined for the server never accidentally gets pulled into the client bundles either.
