logoalt Hacker News

Vibe coded Lovable-hosted app littered with basic flaws exposed 18K users

113 pointsby nottorptoday at 4:48 PM30 commentsview on HN

Comments

recursivedoubtstoday at 7:04 PM

I continue to maintain that the best metaphor for the current situation in software development is "The Sorcerers Apprentice" in Fantasia:

https://www.youtube.com/watch?v=m-W8vUXRfxU

firefoxdtoday at 5:59 PM

Lovable is marketed to non developers, so their core users wouldn't understand a security flow if it flashed red. A lot of my non dev friends were posting their cool new apps they built on LinkedIn last year [0]. Several were made on lovable. It's not on their users to understand these flaws

The apps all look the same with a different color palette, and makes for an engaging AI post on LinkedIn. Now they are mostly abandoned, waiting for the subscription to expire... and their personal data to get exposed I guess

[0]: https://idiallo.com/blog/my-non-programmer-friends-built-app...

show 1 reply
carlgreenetoday at 5:40 PM

The hardest part about this stuff is that as a user, you don't necessarily know if an app is vibe-coded or not. Previously, you were able to have _some_ reasonable expectation of security in that trained engineers were the ones building these things out, but that's no longer the case.

There's a lot of cool stuff being built, but also as a user, it's a scary time to be trying new things.

show 3 replies
melecastoday at 6:07 PM

Vibe coding democratized shipping without democratizing the accountability. The 18,000 users absorbed the downside of a risk they didn't know they were taking.

show 2 replies
aitchnyutoday at 7:10 PM

One dev of a Lovable competitor pointed me to the rules thats supposed to ensure queries are limited to that user's data. This seems like "pretty please?" to my amateur eyes.

https://github.com/dyad-sh/dyad/blob/de2cc2b48f2c8bfa401608c...

ch4s3today at 5:50 PM

I've been thinking a bit about how to do security well with my generated code. I've been using tools that check deps for CVEs, static tools that check for sql injection and similar problems, and baking some security requirements into the specs I hand claude. I can't tell yet if this is better than what I did before or just theater. It seems like in this case you'd need/want to specify some tests around access.

I'm interested to hear how other people approach this.

show 3 replies
aplomb1026today at 6:32 PM

[dead]

octoclawtoday at 6:04 PM

[dead]

julianlamtoday at 5:56 PM

> One example of this was a malformed authentication function. The AI that vibe-coded the Supabase backend, which uses remote procedure calls, implemented it with flawed access control logic, essentially blocking authenticated users and allowing access to unauthenticated users.

Actually sounds like a typical mistake a human developer would make. Forget a `!` or get confused for a second about whether you want true or false returned, and the logic flips.

The difference is a human is more likely to actually test the output of the change.