Your Supabase Is Public

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.

Isn't Supabase anon key actually a publishable one? What's voila about finding it. RLS disabled is a more of a voila here.

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

> 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.

Supabase is great if the goal is insecure, incredibly slow postgres. Selfhosting it is also painful with ~10 separate containers, while supabase's own offering has downtimes that won't appear on their status page.

Only thing it actually makes easier is auth. Other stuff just becomes harder to maintain. A simple springboot Java app, especially with basic boilerplate implemented with llm help, will last a long time, be cheap+simple to host, easily extensible.

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.

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.

Guys, please, stop using all these Vercel-likes. It won't do you any good. There was an excellent article on self hosting PostgreSQL the other day.

https://pierce.dev/notes/go-ahead-self-host-postgres#user-co...

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.

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.

> 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!

- Enable RLS

and/or

- Turn off the REST API (if you just use pg connections)

- Disable the JWT/anon token(s)

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'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!

if your product targeting "dummy user" they should make it dummy foolproof

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.

So like MongoDB twenty-odd years ago?

[dead]

[dead]