Your Supabase is public if you turn off RLS

[mediaman]

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.

[dang]

Ok, we've added "if you turn off RLS" to make the title less misleading. It's still too baity a title for HN, but at least less egregious.

Submitters: baity and misleading titles are against the site guidelines, so please don't post them here.

https://news.ycombinator.com/newsguidelines.html

[SOLAR_FIELDS]

The situation is more nuanced than your comment implies, and a lot of this due to direct product decisions from the Supabase team themselves: https://github.com/orgs/supabase/discussions/4547

The tldr is that Supabase makes this less secure by default because Security is Hard and they don’t want to scare off new users

[Raed667]

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

[giogio]

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

[dmix]

People are using LLMs to generate apps and it's easy for non-technical people to miss this stuff. The blog post mentions https://lovable.dev/ becoming a $300M company, which uses Supabase by default and basically generates React SPA's with no true backend. But random people won't understand this distinction and will want to create full real apps. Doing this serverless is tricky and requires a lot of careful thought to do right.

Lovable is not going to tell them to use a proper auth service or fully secure their data. One Lovable project I looked at had generated an entire custom JS Markdown parser instead of using react-markdown, for example.

[x0x0]

My experience is watching a colleague use lovable which will mostly ignore security. Sure, if you prompt it the system will do something which seems correct, but it will also happily undo that as well.

eg I was trying to help her set up a webhook listener, and it undid our efforts.

These tools seem incapable of building software in the hands of users who don't understand security already.

[bitbasher]

You assume people read. :)

[anxman]

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.

[skilldeliver]

The point is that why they even have to make new users table? Something is driving them in this direction and as a counterexample you have Pocketbase where you don't have to.

[stephenlf]

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.

[SOLAR_FIELDS]

It’s even worse than No Idea what you are Doing. One can, as has been alluded to in other comments, be a completely naive rube who is using Supabase under the hood with v0 or Lovable and not have any idea that you’re even using it or that it exists at all.

[dbcpp]

Related to this, I've been wondering how much we should actually be depending on RLS for. There are known timing attacks against it [1].

[1] https://www.cs.tau.ac.il/~mad/publications/sigmod2023-rls.pd...

[devmor]

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

[jscheel]

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.

[christophilus]

Interesting. That would have surprised me if I was a supabase user. I’m used to tossing everything into the public Postgres schema simply because it’s the default schema, and for many small apps, that’s all you need. Supabase should really rethink publicly exposing the default schema without explicit consent from the developer.

[EGreg]

That is why in https://github.com/Qbix/Streams the default for all streams is PRIVATE. And people can choose what to open up explicitly. We support access templates, mutable access, and inheritance, roles, even participant roles and custom permissions. But the default is private, and all that is machinery on top of it.

Read this for a high level overview useful for HN: https://community.qbix.com/t/streams-plugin-access-control/2...

[k4rli]

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.

[bArray]

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

[PierceJoy]

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.

[pranavm27]

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

[koakuma-chan]

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

[brikym]

It can go wrong. I had a horrible experience with StackGres. I read a lot of positive things about CloudNativePG though. I can see where people with startups are coming from not wanting to manage database plumbing so they can focus on real business tasks. I think that's fine as long as there is a path to self-host after some growth. I might do some event-sourcing myself so that databases are effectively materialized views easy to add and remove.

[wahnfrieden]

That article is good if you don't care about uptime or incident recovery time.

Yugabyte is the best open source postgres for HA.

[int0x29]

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.

[tonyhart7]

to be fair, Auth and access control is just "hard" problem in general tbh

we have so many data breach because they lack "common basic" security best practices, we aren't talking about state level hacker here

just public bucket storage and so on

[veeti]

AWS also had to add some serious warnings into S3 console to stop people from blowing their foot off with public buckets.

[dangoodmanUT]

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.

[teaearlgraycold]

Any time I see a product like Firebase that rolls auth and other major features into a database I roll my eyes.

[tonyhart7]

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

[dmillar]

- Enable RLS

and/or

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

- Disable the JWT/anon token(s)

[fakedang]

So, turn it on? You'll get rid of the constant warnings on Supabase too.

I mean, Supabase strongly emphasizes using RLS in every part of the dashboard. They literally advise you everywhere not to expose the database data anywhere client side.

[ErroneousBosh]

So like MongoDB twenty-odd years ago?