I do not understand how using supabase with a client based framework like svelte or react is secure? Surely you can just pull the the api keys out of memory with some basic debugging software?

There's a public (anon) key, and a server (service role) key. The anon key is not designed to be kept secret. You could commit it to repos, share it via a slack chat... hell, you could post it on social media if you really wanted to. Wanna buy a billboard and post it there? Go right ahead. You can go to any website which is using supabase in the backend, and as long as they're not doing server-side rendering, you'll be able to see network requests to their supabase project - no need for any debugging software other than the dev tools in the browser. What's important is the security aspects. Row-level security is done at the database, and it allows you to define who can access which rows in a table. Current user

id

doesn't match the

id

property of a row? They can't see the row. The service role key should never ever be placed in a public location. Treat is as though it's the key to the kingdom. This key allows you to bypass row-level security. It's used primarily for server-side control. Use cases include API's and database automation. When logging in via third-party (e.g. Twitter), you have to define where the user will be returned to after completing the auth process. If the redirect URL isn't in the allow list you specify, then the user will just be redirected back to one of the URL's that are in the allow list. For example, if someone was to try and direct a user to bad-domain[dot]com, and you only allow users to be redirected to good-domain[dot]com, then the end-user will only be redirected to good-domain[dot]com, meaning that the owner of the bad domain will never receive the details provided by the third party auth provider (e.g. twitter).

thanks scott!