Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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


More likely reason is that Supabase is a BaaS. Between client and DB there is no backend for secret management. So RLS is the only way to directly create API on the DB.


I’m not sure anyone’s scared off by this. It’s more that it’s more intuitive to declare your user queries (like Meteor did or how GraphQL works) than to reason about RLS.


It’s not about being scared off, I’m simply challenging the notion that Supabase is secure by default. It depends on your definition of secure, since everyone has a different threat model, but the above thread demonstrates that probably a good chunk of people would say No, it’s not actually secure by default. Being scared off would be probably the best possible outcome over the current situation which is “we don’t really have a good story to tell about whether this is secure or not”.

The fact that it takes a whole thread of conversation to even unwrap whether the default approach they took is good enough is a strong signal to me that it isn’t, because that level of complexity in the implementation often implies a model with a large enough attack surface with weaknesses that can be exploited without too much effort




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: