upvote
> I've realised that the supabaseKey needed for creating the client on the frontend also grants users access to the database by default.

I can't believe someone actually made this by design

reply
The idea was that RLS (Row-level security) would be enabled on any tables exposed to the data API, and RLS was “heavily encouraged” to be turned on by default in the dashboard, and RLS was on by default since at least 2025. Tables require explicit RLS policies to be accessible by the data API, so by default it’s not open like that anymore.

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.

reply
I believe it
reply
If your goal is to onboard nontechnical users quickly and not have to deal with them churning because they have to deal with thinking about those pesky "security rules" before they can get a working app, it totally makes sense that you would do this, especially if you just drop a get out of jail free "well, it's the end user's fault for not configuring their app securely" in your T&C.

Somehow it's okay to simultaneously set a golden path to less secure software to support your hockey stick growth model and then turn around and blame end users when it all goes wrong.

reply
This 5 year old issue was only just fixed this October? Got a link to where it was fixed?
reply
https://github.com/orgs/supabase/discussions/45329

Any tables created before the defaults put in place are of course still subject to the wide open previous default configuration, because they would risk break existing users apps if they back-ported those.

reply
While we’re at it, I was quite surprised to discover that Supabase leaks schema information through the `hint` field in error messages:

https://docs.postgrest.org/en/latest/references/errors.html

For example, if you try to access a table named "secret" that doesn’t exist, Supabase might return a hint saying, "Perhaps you meant the table 'public.super_secret'."

Thanks for volunteering that information, I guess.

reply
nobody needs supabase.
reply
The amount of misconfigured supabase out there is astounding. And I'm not just talking about your mom's friend who wants a mahjong social network site. Companies backed by sand hill road VCs to the tunes of 10s of millions of dollars expose keys, don't have rls, set anon envs that are really full admin keys, don't rotate keys, etc.. the list goes on. It's wild.
reply
Supabase taking a leaf out of Firebase's playbook, I see.
reply