Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your Supabase is public if you turn off RLS

skilldeliver.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Your Supabase is public if you turn off RLS

#61

Post by blackoil »

SOLAR_FIELDS wrote: post #38
mediaman wrote: post #28

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 compar…

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.

Re: Your Supabase is public if you turn off RLS

#62

Post by anxman »

MoonWalk wrote: post #6
skilldeliver wrote: post #5

Earlier quoted context omitted.

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.

To store application-specific data about users. The Supabase doc or examples show this. Where else would you put such data? But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. I could find no details on what to expect in each column at any given time. Upon creating a new user, values get set in…

The auth schema is intentionally not exposed to the rest api for security reasons. You need to use an auth hook to put data where you need, or an RPC with appropriate privileges, and of course RLS on any tables.

Re: Your Supabase is public if you turn off RLS

#63

Post by anxman »

MoonWalk wrote: post #6
skilldeliver wrote: post #5

Earlier quoted context omitted.

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.

To store application-specific data about users. The Supabase doc or examples show this. Where else would you put such data? But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. I could find no details on what to expect in each column at any given time. Upon creating a new user, values get set in…

https://supabase.com/docs/guides/auth/auth-hooks

These have gotten much less annoying to use now that it’s controlled through the config.toml.

Re: Your Supabase is public if you turn off RLS

#64

Post by cess11 »

wahnfrieden wrote: post #56
cess11 wrote: post #47

Earlier quoted context omitted.

Once you have reason to care about that, then you should also be able to afford to hire people that can sort it out for you.

Not really. Maybe for consumer. But there are many kinds of b2b infrastructure businesses that I can build and launch myself where I wouldn't want to expose myself to risk of day-long outages (for either reputational or as competitive disadvantage of having no HA story), such as anything to do with payment gateways, API gateways, AI proxies or other AI infrastructure - anything where client services would experience…

I'm not familiar with their products but it seems they had a four hour incident a few months ago:

https://status.yugabyte.cloud/history

You should not run a payment gateway on an inexperienced team. Start with something with lesser risk and then introduce the team to things like load balancers, keepalived, clustering and so on over time.

An hour of downtime is a lot once HA is something to invest in, and the first thing you need to do when there's an incident is to tell your customers what you're doing about it and the second thing they want to know is whether it will happen again. Since I don't know how Yugabyte works I'm not sure about the degree of lock-in, but preferably you should have an incident process where you at minute ten or so of downtime boot load balancing with a customer facing message at another infra provider and update DNS records, then start to rebuild the system there in parallel with the main incident response.

Re: Your Supabase is public if you turn off RLS

#65

Post by DANmode »

vrosas wrote: post #58
dmix wrote: post #12

Earlier quoted context omitted.

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 t…

I asked claude to build a system that involved parsing some dates and addresses and rather than using a library it wrote hundreds of lines of regexes and term lists ('st', 'street', 'dr', 'drive', 'ave', etc) to match every test case I gave it. Lesson learned.

What was the lesson,

to ask it to use a library,

if that’s what you intend for your codebase?

Assume LLMs and AI products are a rockstar junior dev until proven otherwise. Act accordingly!

Re: Your Supabase is public if you turn off RLS

#67

Post by fakedang »

MoonWalk wrote: post #6
skilldeliver wrote: post #5

Earlier quoted context omitted.

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.

To store application-specific data about users. The Supabase doc or examples show this. Where else would you put such data? But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. I could find no details on what to expect in each column at any given time. Upon creating a new user, values get set in…

I finally resorted to using Supabase as a Postgres database for Django. In that role, it has worked very nicely.

Re: Your Supabase is public if you turn off RLS

#68

Post by jscheel »

christophilus wrote: post #27
jscheel wrote: post #15

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…

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.

They do a lot more nowadays to make it clear to the user what is happening, but it still feels unnatural to me.

Re: Your Supabase is public if you turn off RLS

#69

Post by iamsaitam »

dmix wrote: post #12
giogio wrote: post #9

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

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 t…

Why should we care about what non-technical people do wrong in a technical domain?
Post reply on HN