AI coding tools have really turned me off from engaging with the vast majority of startups and personal projects online. It used to be that people who had the skills and dedication to launch something of their own could generally be trusted to follow security best practices and be careful with user data, sometimes even more so than large companies. Now it's more likely that someone with marginal technical skills is "vibe coding" to try and make a quick buck.
Completely false about personal projects. The median github repo was crap long before genai. The superstar open source libraries often have high quality, but it is a steep cliff after that. Anybody can push to pypi or npm and I've seen so much crap there too that I was tempted to install after a search, until I looked into the code. That's what genai is trained on.
I suspect it's a long way from what it's meant here by "online personal projects i can interact with" and "median github/pypy/npm crap".
Speaking for myself, I remember a time when personal ("indy") projects had the reputation of being better cared for than big company products before online repositories were even a thing.
It's put me off sharing my code online. Having a project forked is one thing, having someone "vibe coding" my code verbatim and thinking they did it themselves is another.
Yep. I don't even put code that's related to business in private github repos any more; everything goes in a private git forge running on a NUC in my office.
> It used to be that people who had the skills and dedication to launch something of their own could generally be trusted to follow security best practices and be careful with user data
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
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.
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
This is why any DB connections should be "air-gapped" with an API. I use PG on a side project and I don't have RLS enabled but as the time time, a user cannot get/set anything in the DB unless it goes through an API endpoint and the endpoint + middleware ensures that a user has access to whatever they are modifying / reading.
I think Supabase just have bad defaults... Especially for non technical people that they market to.
I think by default they have some sort of public schema which is the default schema and for which PostgREST is enabled. There may be a checkbox to change that during setup but it's not checked by default.
Instead, one should probably use a different schema for the actual tables and create views that define the public API in the public schema.
I am not sure but isn't this something the industry is at a risk of moving from with react frontend engineers insisting on server functions sprinkled in the client code?
Just asking, because it sounded funky when I heard it at first.
Server Functions don't expose ability to query DB from the client (unless that is specifically what you're trying to do). You can think of them as "syntax for endpoints". They don't change which code runs where.
They still execute on the server. Server and client code is never mixed in the same file, and there is a way to enforce at the build time that code destined for the server never accidentally gets pulled into the client bundles either.
It would not be surprising if half of the pre-"vibe coding" mobile apps that use Supabase have the exact same security holes. This is really nothing new, it's inherent to RLS being just the technology that sounds incredibly convenient to beginners yet comes with the right footguns they are likely to miss, despite Supabase doing its best with warnings in the UI. I think SB is a cool company that means well, but RLS will never be reliable. It takes too much discipline to use safely and reliably on any meaningful project, and at that point it's simpler to just roll an API or a few serverless functions.
One does wonder how much bad insecure code is out there now being fed into LLMs to generate.. more bad code. The more you lean on something else to write your code, the less you understand what you're shipping.
Readit News
Speaking for myself, I remember a time when personal ("indy") projects had the reputation of being better cared for than big company products before online repositories were even a thing.
Did it? I'm not so sure.
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.
This is not a problem with Supabase.
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.
I think by default they have some sort of public schema which is the default schema and for which PostgREST is enabled. There may be a checkbox to change that during setup but it's not checked by default.
Instead, one should probably use a different schema for the actual tables and create views that define the public API in the public schema.
I just googled this and it seems to be even recommended in the PostgREST documentation itself: https://postgrest.org/en/v10/schema_structure.html#
Just asking, because it sounded funky when I heard it at first.
They still execute on the server. Server and client code is never mixed in the same file, and there is a way to enforce at the build time that code destined for the server never accidentally gets pulled into the client bundles either.
See here for an overview. https://overreacted.io/what-does-use-client-do/#use-server
BaaS sounds cool but, for small apps, understanding and configuring RLS is a lot harder than writing a backend to expose only what you want.