One of the golden rule of webdev is "never build your own auth" for a reason.

To me, it feels like Lovable is an irresponsible product selling the idea that web development is trivial now with LLMs, where the reality is that although it's true that agentic coding means while anybody can spin up a website in like 10 minutes, a professional software engineer who knows what they are doing can still utilize LLMs much more effectively than an amateur ever could.

I don't see any indication in the post that these cases involved someone writing their own authentication code. This is about authorization mistakes, or the lack of any authorization. And that part you have to write yourself in some way (even if you use libraries), someone has to define the rules about which data is accessible under which rules. Using a pre-made library won't save you from defining those rules wrong.

To me only hard rule like this is to never implement your own cryptographic code. A decent developer can easily implement simple session-based authentication safely, or at least I'd suspect the chance of mistakes is no higher than this developer misconfiguring a much more complex library for authentication.

Where is that rule written? You can build a really solid auth system, if you follow the rules. Also, what kind of auth method are you mentioning?

That's not the problem here. Lovable uses the Supabase Auth layer; they just have their own interface on top of it.

Supabase is kind of similar to Firebase in that you usually communicate directly with the browser through a JavaScript lib. So you need to pay close attention to the security rules (RLS policy in Supabase's case) to restrict data per row based on the user auth.

It's easy to get it wrong; that's why so many Firebase and Supabase databases end up exposed. The platforms have improved the UX so that it's not so common anymore, but it's definitely a gun that's easy to shoot yourself with.

You don't have to expose it like that. You can disable that client and use a server to communicate with the database, which reduces the exposed surface in exchange for complexity (by even having a backend at all).

Mix that design with users with zero tech background who know nothing about systems design and LLMs, and you have a recipe for disaster.

We use Lovable as a prototyping tool and then eject it, review, and deploy on a different platform. It works great for that use case.

No? The rule is don't roll your own crypto. Building your own auth is normal and learning to do so ought to be expected as part of the standard education of a backend developer. I suppose next I might hear something like never define your own table schemas...