upvote
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.

reply
In the article:

>In its marketing, Lovable repeatedly emphasizes that no technical knowledge is needed to build projects. This can give the impression that the platform takes care of security too. Yet Lovable’s Terms & Conditions place responsibility for applications and data handling on the customers themselves.

My point is that the way Lovable websites are generated pretty much made no auth or mistake prone from scratch auth stack the default path with no regard to the security problem down the line, and the people they are marketing to are not decent developers or developers at all really, but people who doesn't have much knowledge about software, which is irresponsible.

reply
[dead]
reply
I've started putting OIDC auth in front of my app (at the gateway level) so that no matter how badly my LLM botches the app, requests can't get through.

This only really works with 1-person apps though. If you need multiple users then you have to match the login with specific database records to make sure you're only exposing the right stuff.

I guess that is to say, even if your authentication is great, you can still botch the authorization.

reply
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.

reply
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?
reply
The thing is that in auth (like in cryptography) the rulebook is 2000 pages and there is an annotation book of another 2000. If you miss one page, the llm doesn't and will open you like a tuna can.
reply
What 2000 page auth(n) are you referring to? authn may use aspects of cryptography but it’s largely orthogonal. The point is, it’s fine to roll your own authn.

If you don’t want to roll your own authn, you’re delegating to oauth (oidc) identity providers like google/apple/facebook/etc., which not everyone has an account.

reply
[dead]
reply
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 web developer. I suppose next I might hear something like never define your own table schemas...
reply