Hacker News Reader

Comment by Kuraj | Hacker News Reader

The takeaway that vibe coding introduces security holes by default sounds sensible to me. But also the security issue with Postgres sounds like something I could run into myself even when coding by hand, to be honest

View on HN

Honestly the problem is more that Supabase, in the interest of making it easier to onboard to their product, leaves several important Postgres security features in a suboptimal configuration by default in their product. In particular the settings around how auth and RLS are configured are not optimized for security, but rather to remove roadblocks that devs might encounter the first time they set up the project.

One particular example of this is that anonymous access, as hinted in the article, is turned on by default and it’s not straightforward to just disable it, it requires some in depth knowledge around how the Postgres security model works to do it correctly.

That isn't true representative of Supabase. Tables respect RLS by default, unless turned off. This is how Supabase works. Views are not, and that is due to multiple reasons which Supabase documents. Supabase also warns the user of this and asks them to configure RLS properly for views by first changing the invoker. They also report the same issue to the user on their Security Advisor. The fix is as easy as running the SQL statement in the SQL Editor. Supabase also offers "Autofix" next to the warning, which tells the user exactly how to modify the CREATE VIEW statement to enable RLS.

This is not a problem with Supabase.

See https://github.com/orgs/supabase/discussions/4547

For an in depth discussion of the type of issues I am referring to

It is a problem with Supabase as it's a problem inherent to RLS, and Supabase pushes very hard for RLS to increase adoption by non-technical users like the person who this article is about. You're right that they give lots of warnings to mitigate the issue but the people who they're targeting with RLS are exactly those who ignore them - see this post. This is nothing new and not a consequence of vibe coding. It's the contradiction between RLS being a technology that requires much more discipline to use securely compared to its alternative (a layer inbetween client and DB), yet is marketed and most used by beginners who lack the ability to maintain this.

(supabase ceo)

> pushes very hard for RLS to increase adoption by non-technical users

We are tailoring what we're doing for this audience. The challenge is that they appeared out of nowhere about 6 months ago and the LLMs that are used by this audience is trained on 5 years of content tailored for developers

this is not an excuse, I'm just adding color. We've made a lot of changes with tools, alerts, email warnings etc. We are in planning-mode for changing defaults and working with the AI Builder platforms. We will likely change the schema configuration and advocate for Edge Functions (serverside Typescript) where appropriate.

A long time ago in a land far away, human devs were putting everything including plaintext password files into open publicly accessible s3 buckets.

I guess the training data has more demos of people doing it the wrong way than examples/blogs/articles about how to do it properly.

That's true, though it also seems like the author was a lot more hands-on than most vibe coders I've seen. They even used their own brain(!), rather than just saying "fix it" to the chatbot

Reply on news.ycombinator.com