alt Hacker NewsThe part people are ignoring is Supabase's culpability in this matter: https://github.com/orgs/supabase/discussions/4547
This was supposedly fixed on October 30, but there are reports floating around that for existing projects, the defaults still apply.
Lovable deserves some heat for using this, but this was a choice that was made by Supabase many years ago to support making it easier to onboard potential customers, a deliberate tradeoff of less onboarding pain for less security.
Replies
This 5 year old issue was only just fixed this October? Got a link to where it was fixed?
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.
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.
Supabase taking a leaf out of Firebase's playbook, I see.
> 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