Hey folks, just found supabase. Sounds interesting but - with the SQL is coming via client app isn't that a SQL injection waiting to happen? What's the security mechanism there? I couldn't find that info in the docs.

Hello @tcurdt! This thread has been automatically created from your message in #843999948717555735 a few seconds ago. We have already mentioned the @User so that they can see your message and help you as soon as possible! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ``...`` menu) and select "Leave Thread" to unsubscribe from future updates. Want to change the title? Use the ``/title`` command! We have solved your problem? Click the button below to archive it.

There is no SQL execution that happens on the client, it all happens on our server. We are making use of https://postgrest.org/en/stable/ under the hood for this.

Of course the SQL execution happens on the server, but the javascript client sends the SQL to be executed. What measures prevent me to send a malicious SQL from the client? @silentworks

Please take a look again at the library I referenced, there is no SQL being sent from the client, its a RESTful API being called.

So this gets turned into a REST query?

const response = await supabase
    .from('secret_table')
    .select('*')

Yes correct, if you open your browser console and look at the fetch/xhr request you should see a rest endpoint

That's a good suggestion. Thanks.

You will see a request to a url like

https://random_string.supabase.co/rest/v1/secret_table?select=*

And similar for insers/deletes I guess.

Correct

I know there is row level security - but when there are columns that need to be secured one would create a view to secure those columns, correct?

Except it would be a

POST

(insert),

PATCH

(update) and

DELETE

(delete) request

of course

I don't think this is possible with the current version of Postgres, I think a feature to add RLS to views is coming in Postgres 15. However you can use SECURITY INVOKER for some sort of security around views

you mean CLS - not RLS?

views are executed with permissions of the view owner. If the view owner is a superuser it's mostly gg (they bypass rls by default). I create a new role

api

that owns the views.By default it does not have any permissions on the tables in the

private

schema and i grant those on a table per table basis