"I vibe coded and shipped an app in three days. It got hacked. Twice."(threadreaderapp.com)
threadreaderapp.com
"I vibe coded and shipped an app in three days. It got hacked. Twice."
https://threadreaderapp.com/thread/1929017755136561402.html
62 comments
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.
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.
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.
I'm not alone in this and we don't need to go much further back than the early '00s! Great time to sample from.
I had a Mac at the time so here's some from the top of my head that I remember being very popular: Quicksilver and LaunchBar, NetNewsWire, Coda and Transmit (anything from Panic, really), Growl, AudioHijack and Soundflower, Unarchiver, iA Writer... these were insanely well crafted apps with no real competition from big companies in that regard.
Apple infamously capitalized on this indy development phenomenon with the creation of the AppStore model in 2008, first on the iPhone and later on the Mac.
Outside of this ecosystem I can remember WinAmp, Total Commander, WinRar, 7-zip, VLC, Foobar, mIRC, Paint.NET, μTorrent, FileZilla, Reaper, SublimeText...
Macromedia was a medium sized company with huge global success for their size, and they had some of the best software out there at the time before their acquisition. Adobe immediately polluted it.
Thoughtful, ad-free, bloat free, passion-driven software with attention to detail, good design and great performance was an attribute of small independent teams, not big software companies.
I had a Mac at the time so here's some from the top of my head that I remember being very popular: Quicksilver and LaunchBar, NetNewsWire, Coda and Transmit (anything from Panic, really), Growl, AudioHijack and Soundflower, Unarchiver, iA Writer... these were insanely well crafted apps with no real competition from big companies in that regard.
Apple infamously capitalized on this indy development phenomenon with the creation of the AppStore model in 2008, first on the iPhone and later on the Mac.
Outside of this ecosystem I can remember WinAmp, Total Commander, WinRar, 7-zip, VLC, Foobar, mIRC, Paint.NET, μTorrent, FileZilla, Reaper, SublimeText...
Macromedia was a medium sized company with huge global success for their size, and they had some of the best software out there at the time before their acquisition. Adobe immediately polluted it.
Thoughtful, ad-free, bloat free, passion-driven software with attention to detail, good design and great performance was an attribute of small independent teams, not big software companies.
These are all examples from 20 years ago. Anything more recent?
I mean thats also the case for enterprise software, shit banks have breaches every couple months lol
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.
I'm moving my new private repos off Github too, I don't trust Microsoft not to train LLMs on it.
> 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.
Did it? I'm not so sure.
That might have been closer to the truth in the 90s, but certainly not since the SWE gold rush
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.
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.
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
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.
> 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.
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
This thread-converted-to-blogpost highlights exactly how annoying it is to read information published in chunks. More on that later.
Engage! Ment! Make it so! I feel startracked already ..
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.
Firebase/Supabase is that API. Of course you then need to configure the API tier correctly, which only pushes the problem further one step.
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 just googled this and it seems to be even recommended in the PostgREST documentation itself: https://postgrest.org/en/v10/schema_structure.html#
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#
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.
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.
See here for an overview. https://overreacted.io/what-does-use-client-do/#use-server
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
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.
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!
[0] https://github.com/orgs/supabase/discussions/34270
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!
[0] https://github.com/orgs/supabase/discussions/34270
(supabase ceo)
> Supabase's official reply about this question is "I guess you can, but don't worry, RLS."
Here is a more representative view of our official reply:
https://supabase.com/docs/guides/database/hardening-data-api
To avoid both 1 and 2 I would suggest creating a `private` schema. We are now in the planning stages to make this the default
> Supabase's official reply about this question is "I guess you can, but don't worry, RLS."
Here is a more representative view of our official reply:
https://supabase.com/docs/guides/database/hardening-data-api
To avoid both 1 and 2 I would suggest creating a `private` schema. We are now in the planning stages to make this the default
> We are now in the planning stages to make this the default
This is excellent news!
I apologize for my "disaster" wording. I had to eat some hours for that, and I am a bit salty. This was a tough thing technically for you guys, and it's likely more about future users. I get it. However, hacking my old migrations did feel very icky.
All that aside, I would like to genuinely thank your team for reading my reddit comment about my argument for MCP --read-only, and only a couple of days later coming back with ~"Yeah, that actually makes sense, we are doing it."
On HN, we are used to YC-funded CEOs chiming in sometimes, but you guys created a feature based on my rando reddit comment, because it made sense. That's an org I want to work with. I should have made my original comment more accurate about my feelings.
This is excellent news!
I apologize for my "disaster" wording. I had to eat some hours for that, and I am a bit salty. This was a tough thing technically for you guys, and it's likely more about future users. I get it. However, hacking my old migrations did feel very icky.
All that aside, I would like to genuinely thank your team for reading my reddit comment about my argument for MCP --read-only, and only a couple of days later coming back with ~"Yeah, that actually makes sense, we are doing it."
On HN, we are used to YC-funded CEOs chiming in sometimes, but you guys created a feature based on my rando reddit comment, because it made sense. That's an org I want to work with. I should have made my original comment more accurate about my feelings.
> reading my reddit comment about my argument for MCP --read-only
it was great feedback, thank you!
it was great feedback, thank you!
[deleted]
The hacks had to do with misconfigured databases, not directly related to the vibe coding
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.
My understanding is the notion is about getting an application to "work" without any underlying theory of operation or evaluation of the imported context.
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.
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?
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
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
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.
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.
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 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.
> 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"
Pray tell, what is a good choice then?
.
.
... anything you already know yourself to secure so you can correct the "AI"
> 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.
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.
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)
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.
[deleted]
"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".
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.
Push out crap, hope it sells, leave the problem for someone else to figure out.
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.
Make the minimum thing people will pay money for and hope that a bigger fish gobbles you up.
[deleted]
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.
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.
> you must possess the will to dominate.
> Internet citizenship isn't a right
> If you can't fight then go back to Facebook where you belong.
Respectfully, these phrases sound a bit toxic and elitist tbh.
Perhaps you meant that the net is a bit like the wild west, so one best bet mindful of the dangers?
As another commenter mentioned, don't complain your house was broken into if you didn't have locks on the doors.
> it's something LLMs won't help you with.
That phrase, however, is spot on.
> Internet citizenship isn't a right
> If you can't fight then go back to Facebook where you belong.
Respectfully, these phrases sound a bit toxic and elitist tbh.
Perhaps you meant that the net is a bit like the wild west, so one best bet mindful of the dangers?
As another commenter mentioned, don't complain your house was broken into if you didn't have locks on the doors.
> it's something LLMs won't help you with.
That phrase, however, is spot on.
Have you ever built a piece of software from scratch and put it online?
I have, actually, but that's irrespective of my comment on exclusionism.
Everyone has the freedom to put something online and watch teenagers destroy it. What could be more inclusive?
Share your online service if you've got one. If you want, you can try and take down mine: https://ipv4.games/
Share your online service if you've got one. If you want, you can try and take down mine: https://ipv4.games/
> to put something online and watch teenagers destroy it.
Lol you're quite right there.
> Share your online service if you've got one.
I don't have anything that's not work anymore.
I got burnt out about a decade and half ago, and since then it's been just work, analog life, and the occasional touch up of a couple of personal projects in dark consoles.
Lol you're quite right there.
> Share your online service if you've got one.
I don't have anything that's not work anymore.
I got burnt out about a decade and half ago, and since then it's been just work, analog life, and the occasional touch up of a couple of personal projects in dark consoles.