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
This thread-converted-to-blogpost highlights exactly how annoying it is to read information published in chunks. More on that later.
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.
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.
Vibe coding is a contributing factor, but I suspect the root cause is an overly complicated architecture. I can smell the spaghetti from here.
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.
Others have pointed out that this is more about Supabase than it is about "vibe coding." As someone just learning to use Supabase myself, the 2 biggest pieces of advice I have are:
1. Put anything that you don't want to be accessible by anon in a schema other than "public." This seems obvious, but the public schema is Supabase's default behavior. Supabase's official reply about this question is "I guess you can, but don't worry, RLS." However, security is an onion. Put up as many barricades as you can. If I was king of Supabase, I would err on the side of security.
2. Login to Supabase Studio, set your role to "anon" instead of "postgres" and click on every single table and view that should be private, and make sure there are no results.
Supabase could do a lot better about communicating this, and it would require no breaking changes unlike this disaster[0] which requires hacking your historic migrations!
The hacks had to do with misconfigured databases, not directly related to the vibe coding
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.
"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".
Seems like there is an opportunity here for the next level of vibe coding - when you have actual paying customers.
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.
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.
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.