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.
Cheer2171 · 15h ago
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.
jrvieira · 13h ago
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.
EdwardKrayer · 2h ago
Can you give some examples? Because personally, I don't remember any period where personal projects weren't normally hacked together, but my experience only goes back to the early 2000s. It would be interesting to hear your memories of it.
cchance · 11h ago
I mean thats also the case for enterprise software, shit banks have breaches every couple months lol
Rendello · 13h ago
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.
herodotuscat · 4h ago
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.
Rendello · 3h ago
I'm moving my new private repos off Github too, I don't trust Microsoft not to train LLMs on it.
arrowsmith · 13h ago
> 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
Did it? I'm not so sure.
mystified5016 · 5h ago
That might have been closer to the truth in the 90s, but certainly not since the SWE gold rush
Kuraj · 18h ago
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
SOLAR_FIELDS · 17h ago
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.
m_sahaf · 16h ago
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.
For an in depth discussion of the type of issues I am referring to
jjani · 12h ago
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.
bodge5000 · 9h ago
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
_fat_santa · 15h ago
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.
paxys · 15h ago
Firebase/Supabase is that API. Of course you then need to configure the API tier correctly, which only pushes the problem further one step.
sureglymop · 5h ago
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.
danabramov · 12h ago
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.
This has nothing to do with vibecoding, and everything to do with exposing your database directly to the internet.
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.
vibedout · 17h ago
This thread-converted-to-blogpost highlights exactly how annoying it is to read information published in chunks. More on that later.
ashoeafoot · 17h ago
Engage! Ment! Make it so! I feel startracked already ..
h2782 · 1h ago
Supabase has a lot of sharp edges that you really need to account for. It's kind of shocking how easy it is to give the world way more access than you intended when using Supabase.
No comments yet
ungreased0675 · 15h ago
Vibe coding is a contributing factor, but I suspect the root cause is an overly complicated architecture. I can smell the spaghetti from here.
rowanseymour · 14h ago
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.
jjani · 15h ago
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.
emrah · 19h ago
The hacks had to do with misconfigured databases, not directly related to the vibe coding
grumpymuppet · 18h ago
Were the database configurations "vibe coded"?
My understanding is the notion is about getting an application to "work" without any underlying theory of operation or evaluation of the imported context.
joshuanapoli · 16h ago
Supabase is really tough to make secure, and it is probably a poor choice if you are interested in vibe coding. Row Level Security is likely to be insecure if the author author doesn't have a deep understanding of Postgres or isn't paying careful attention to all of the generated code relevant to the database.
aitchnyu · 15h ago
Is there a low-code backend/full-stack which is secure by default? I remember some clunky UI to define filters and projection in Firebase. Can a Django/Laravel app weekend project get there before Supabase?
jjani · 12h ago
Just "vibe coding" something minimal in a Cloudflare Worker, or even, ironically, a Supabase Edge Function that directly connects to the DB would 9 out of 10 times lead to something more secure than using RLS. The LLM will always default to RLS when using Supabase as that's what they promote the hardest in marketing materials, so that's what it's trained on.
dghlsakjg · 13h ago
Secure by default? No such thing by virtue of the fact that security is case dependent.
That said, all of the full fat frameworks make it pretty easy to define what should and shouldn't be visible to what users, the use case that he has would not have been harder to do using rails, phoenix, django, etc as a backend, and it would have been very easy to control the failures that he had.
jjani · 12h ago
It doesn't have to be full fat, it can be literally anything as long as it provides a backend layer inbetween the DB and the FE. It can be a single Typescript file that uses literally whatever the LLM defaults to, probably Express given its training materials, or Hono for something more modern, or any of the 1000 other options.
TZubiri · 12h ago
Just write SQL queries, sanitize them, use unix users or selinux to restrict system users.
It has it's dangerous spots, and it's uncomfortable spots, but we pretty much know all about them already, and usage is heavily documented.
Or you can try ORM74 and hope it is faster and more secure than THE standard way. Gamble away.
Or maybe try Framework 74b which abstracts away the ORM
nottorp · 14h ago
> and it is probably a poor choice if you are interested in vibe coding
Pray tell, what is a good choice then?
.
.
... anything you already know yourself to secure so you can correct the "AI"
joshuanapoli · 6h ago
> anything you already know yourself
I think that this is the answer. Maybe someone who is great with Postgres Row Level Security will have an OK time with Supabase security, even if they are vibe coding. They wouldn't think of asking the AI for something that won't work.
skydhash · 16h ago
Frontend is always in insecure land. There's no such things as secure and insecure code there (there may be correct and incorrect code). You can't trust anything that originates from the frontend (anything that comes outside of your servers really)
jart · 11h ago
Whenever you put something new you made on the Internet, people will hack and ddos the hell out of it.
In order to put something online and have it stay there, you must possess the will to dominate.
Internet citizenship isn't a right and it's something LLMs won't help you with.
If you can't fight then go back to Facebook where you belong.
antifa · 10h ago
"I forgot to put a lock on my front door and got broken into. Twice."
wow great security advice, maybe add another pro tip like "look out the front window when you vibe drive your car".
nkotov · 15h ago
Seems like there is an opportunity here for the next level of vibe coding - when you have actual paying customers.
CyanLite2 · 14h ago
Vibe coding is enabling personal startups to be the modern day MLM pyramid scheme.
Push out crap, hope it sells, leave the problem for someone else to figure out.
DrillShopper · 14h ago
That has been the median Silicon Valley startup for the last three to five decades.
Make the minimum thing people will pay money for and hope that a bigger fish gobbles you up.
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.
For an in depth discussion of the type of issues I am referring 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 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.
No comments yet
My understanding is the notion is about getting an application to "work" without any underlying theory of operation or evaluation of the imported context.
That said, all of the full fat frameworks make it pretty easy to define what should and shouldn't be visible to what users, the use case that he has would not have been harder to do using rails, phoenix, django, etc as a backend, and it would have been very easy to control the failures that he had.
It has it's dangerous spots, and it's uncomfortable spots, but we pretty much know all about them already, and usage is heavily documented.
Or you can try ORM74 and hope it is faster and more secure than THE standard way. Gamble away.
Or maybe try Framework 74b which abstracts away the ORM
Pray tell, what is a good choice then?
.
.
... anything you already know yourself to secure so you can correct the "AI"
I think that this is the answer. Maybe someone who is great with Postgres Row Level Security will have an OK time with Supabase security, even if they are vibe coding. They wouldn't think of asking the AI for something that won't work.
In order to put something online and have it stay there, you must possess the will to dominate.
Internet citizenship isn't a right and it's something LLMs won't help you with.
If you can't fight then go back to Facebook where you belong.
wow great security advice, maybe add another pro tip like "look out the front window when you vibe drive your car".
Push out crap, hope it sells, leave the problem for someone else to figure out.
Make the minimum thing people will pay money for and hope that a bigger fish gobbles you up.