So like MongoDB twenty-odd years ago?

Supabase doesn’t make a public users table by default. The user schema is in auth and secured. The problem is that unskilled developers bypass those controls out of convenience and put data into Public without RLS. Even the Supabase docs warn against this.

Firebase seems to suffer a similar problem of people not setting permissions right. The only major difference is that they seem to steer devs pretty aggressively to Google auth which won't leak password hashes.

While in theory your API can be the database it seems like a footgun for the inexperienced and AI.

> I think what's happening is people are creating additional public users tables and not setting proper RLS for them

Yep: https://supabase.com/docs/guides/auth/managing-user-data

> For security, the Auth schema is not exposed in the auto-generated API. If you want to access users data via the API, you can create your own user tables in the public schema.

My experience with supabase is it does actually warn you constantly if you don't set up RLS

> Of course when a friend sends me their new project my natural tendency is to try hack it.

Yep. Probably the most relatable tech friend thing to do. I send my projects to friends and get a list of improvement suggestions, it's always fun!

The problem is that people just really do not comprehend what the "public" schema means in supabase. My guess is that that they think it means "default" or something along those lines. If you read the supabase documentation, you can clearly see that it says "your database's auto-generated Data API exposes the public schema by default", but to truly understand that, you need to understand what the data api is and how it relies on rls. For people first coming to supabase, they are probably either new devs, or they think of the db as a backend service that has application-layer authentication in front of it.

> I'm not going to blame the vibe-coding wave entirely.

As one vibe-coding's most fervent critics, I don't blame it at all. Amateur devs have been doing this for a decade and change with Firebase and other hosted datastores.

I got one of my first small jobs as a contractor because of an Android app doing this back in 2012!

> Maybe it can be simple if check if they create users table there should be a massive red warning popup explaining that everything in this table will be public unless RLS is enabled.

https://imgur.com/KBnmRSq

Just FYI, this is what users see when they try to turn off RLS in a public table (it is on by default). We also show security issues in the project homepage and red alerts in the table editor.

After seeing the responses, I believe that this is more evidence of the fact that Supabase is easy to work with (and thus attracts people who have NO IDEA what they’re doing), and less an issue with Supabase security.

I find that supabase is pretty good at warning you about these things in their project specific security advisories, but obviously you need to actually pay attention to them and then take action.

I don't understand this. In supabase, the default is to turn on RLS for new tables. If you turn it on and have no policy set, no user can fetch anything from the table.

You have to explicitly create a read-all policy for anon keys, and with no constraints, for people to get access to it.

The default is secure.

If you turn off RLS, there are warnings everywhere that the table is unsecured.

The author goes on to compare this with PocketBase, which he says you "have to go out of your way" to make insecure. You have to go out of your way with Supabase, as well!

I wonder if the author tested this? I do agree that some third party website builders who use supabase on the back end could have created insecure defaults, but that's not supabase's fault.

One thing I find about these "all in one" platforms is that they tend to lure people into a sense of "wow this is easy to use" such that they forget to check security, assuming it's covered.

This is one reason why Firebase was such a gold-mine for security researchers: everyone just forgot about security when they forgot about their backend.