> the people affected here are end users who did not action provided findings.

7500 site operators failing to "action provided findings" seems like some systematic failure on your part and you should accept some responsibility for it. Don't allow users to publish apps if you know they leak private data.

That's our thinking with auto-fix - no matter how good are findings or warnings, or modals blocking publish, some apps will still do it. We work hard on promoting auto-fix, and free fix-all functionality so that users do not hesitate to use it.

Seriously?

Was my reaction then I remembered the world of tech as it currently is and was both not surprised and yet still disappointed.

This is the new future, I'm just not sure I want to be part of it.

It’s really disheartening and disappointing to see how little you can take ownership of Lovable’s part in this. This post doesn’t say “disparate, unconnected apps expose passport details.” These are lovable apps, your apps on your ecosystem. Own it.

Yes. Lovable is pretty much untouchable for serious businesses going forward until they clean up this mess. And even then.

[delayed]

Lovable more-or-less presents itself as 'Wordpress for applications'. That comes with a whole pile of responsibilities and a large chunk of their customers may think they are doing a good thing by picking them instead of hiring a dev team.

"Build something Lovable

Bring a new product, internal tool, or entire company to life."

You can't market like that without having the back-end rock solid. There isn't a word about risk or responsibility there, but there are plenty of disclaimers of responsibility in their terms of service and the CISO (active in this thread) does not inspire confidence.

We are investing millions per year into free security tooling. There will be even more changes democratizing security coming out soon, with more features moving to Free/Pro tiers from higher tiers - watch our release announcements. Free and accessible is our core strategy for security features. It's our way to act on the feedback, accept the blame, and find new ways to engage the users and help them fix their apps. I think it's important to be here and engage in the discussion - to learn, share my point of view, and get back to work on securing every app on Lovable with more insights of struggles and issues of builders and the community.

Idk why I’m acting like a person read my comment. May as well ask you to write a sonnet for all this addressed what I said

Would it be better to right now risk forcibly (for new apps) breaking a few things to prevent passport details from leaking?

I think the problem is rooted in consideration of the architecture itself. The post mentioned one of the common patterns where people leave permissions too wide, suggestion is to let another LLM take a run at it to make some changes.

My personal reading is that people find it easier to put another bandaid on the top of existing one on the name of security. A sprawl of monitoring and automation tool give a sense of security while adding to the cost. It might be worthwhile to let it be visible to user, who can see the data, who can modify the data when it comes to self vs other and authenticated vs unauthenticated. And of course people are going to try to save money, these scanning features are going to show up as additional bill pretty soon.

We noticed that many projects come from earlier builds. Roughly speaking, building an insecure app is much harder today than 6-12 months ago. Agent will protest and try to suggest alternatives if the builder asks to have no security, for example. But some folks find it easier to build with no RLS and then add them later. But for a complex app, it's a hard task, things break etc. In our blogs, videos and office hours, I always recommend building with all security features on from the beginning, never trying to slap it on top after the fact

We are committed to keeping scanners free. A new UX for security rolls out soon (this month), will get a better understanding of what is wrong, who can see what and why important to fix.

Yes unfortunately security suffers a similar fate everywhere. For MVPs its a cost which is not tied to any revenue so it gets pushed on. Over the period of time you have built ecosystem of applications and services in a incremental way to provide features that customer asked for. Ironically no customer asked for the security explicitly, it was that non-functional requirement that exists in bare bones in some form. Its most likely not the part of architecture for sure in almost all the places, if an architecture exists.

The biggest revenue you will get is from enterprise customers and thats your biggest risk too if security goes south. You already have advantage of being close to customer stories and usage behavior. Some one within the company needs to build the platform again from grounds up with all these security requirements baked into the architecture, sort of parallel project one would say.

> We are committed to keeping scanners free.

This sounds like a good sentiment in theory, however this is a double edged sword. Scanning costs money to you as company and that cost is going to make it to the customer one way or another

Indeed, we are looking into having a path to take down apps that grossly violate privacy and data protection. It's a bit tricky legally so we need to find a good balance. Our thinking is so far: notification with ask to fix, grace period, if no action and no improvement - soft block until issues fixed.

> some apps will still do it.

> these apps

Why do these companies think of their customers as total morons. Publicly demeaning them and blaming them for being victims of their stupidity is beyond ridiculous.

> And that's why I believe auto-fix will solve a lot of problems in this space

Then why didnt you do it. Why would users be interested in your 'thoughts'

Auto-fix is tricky to get right without breaking the apps (imagine us having 99% of auto-fix success, at the scale of 10M apps, it would mean breaking 100 000 apps). We need to get really good at it - otherwise people will be burned by it and will never trust it again. But it's getting really good, I hope we will be able to release soon.

> We need to get really good at it - otherwise people will be burned by it and will never trust it again

As opposed to?

Then why were those apps allowed to run unsecured for so long that they gained enough users and their owners developed said fear about security fixes? Why do they have said fears in the first place? Maybe they don't trust your platform? You said you're company is committed to make security accessible - well, you failed big time. Yet you're unwilling to accept any blame and instead you're trying to shift blame to your users.

It's infuriating how little responsibility you are taking. And it's downright shameless of you to come here with this attitude and try to soothe the outrage with AI speak.

> Why do they have said fears in the first place? Maybe they don't trust your platform?

To be fair, one can harbor a fear of updating after bad experiences with entirely unrelated software.

We are investing millions per year into free security tooling. There will be even more changes democratizing security coming out soon, with more features moving to Free/Pro tiers from higher tiers - watch our release announcements. Free and accessible is our core strategy for security features. It's our way to act on the feedback, accept the blame, and find new ways to engage the users and help them fix their apps. I think it's important to be here and engage in the discussion - to learn, share my point of view, and get back to work on securing every app on Lovable with more insights of struggles and issues of builders and the community.

The fix is security by design, not the "auto-fixes" you ask customers to apply.

Yeah, exactly. Enforce security even if it breaks apps after, say, a 7 day or 14 day cool off. Lovable markets itself as offering a solution for building apps to those who lack technical skills so should take more responsibility. Saying “we told people” and then washing their hands of it isn’t acceptable because their target market doesn’t understand the technicalities.

> Work on educating users (...)

unacceptable! it's all about the vibes!

How are you going to make sure that none of the data that escaped your control is going to be mis-used?

Have you made an inventory of all of the places where the data ended up?

Have all parties that ended up with copies confirmed the copies are destroyed and had not been passed on?

Have you reported an inadvertent disclosure to the DPA?

Isn't Lovable in this case more analogous to a consultancy to whom customers outsourced their website builds — meaning the customers, not Lovable is responsible for these actions?

On a larger note, and not at all to downplay the seriousness of this breach, but this feels like the kind of growing pain we're going to continue going through as we move to an AI-driven world. Who's responsible for the work of the AI? In this case, I think it's pretty cut and dry, since Lovable sells a service that _happens_ to be powered by AI (it could just as easily have been done by an outsourced team instead). But as AI gains more agency, it's going to become less and less clear…

[delayed]

This is what Lovable's terms say:

  # AI Output
  
  The Services may use artificial intelligence models to
  generate code, content, or other outputs ("AI Output").
  AI Output may contain errors, inaccuracies, or other
  issues and should not be relied upon without
  independent review and testing. You are solely
  responsible for reviewing, validating, and using any
  AI Output, whether it is generated through:
  
  - our Platform's integrated AI;
  - the AI Gateway (via Third-Party AI Providers); or
  - any model or API that you connect to the Services.

https://lovable.dev/terms

Disclaimers don't trump law. I'd love to see this tested in court.

I've never used lovable; do they have any sort of human-approval gate step between (or around) generating an app and deployment/availability? INAL but I wonder if that would CYA for responsibility of releasing bad code created by their AI...

Those are all good questions, I think the customers' perception is that they have outsourced this but obviously they too have a responsibility (for instance: to do due diligence on the parties they do business with to make sure that they are observing their duties as controllers). One thing is certain: the data subjects are without blame and their interests have been violated substantially, the question really is what else happened to the data and that is something that nobody knows right now. But if it is true that it ended up on common crawl then that would be quite a big problem.

To clarify: no PII leaked from Lovable apps ended up in Common Crawl. Common Crawl was used solely to identify Lovable apps—not to retrieve leaked data. It does not store XHR responses, which are how data is retrieved from Supabase.

Ok. One commenter in this thread was adamant that that was the case: https://news.ycombinator.com/item?id=50501973 you may want to clarify this there as well.

As with many gray areas in the law, this all likely comes down to a reasonableness test. New laws may be needed but, to the fullest extent possible, these issues will be framed through the lens of existing law—e.g. product liability. And, once tested in court, these will likely lead to new precedents around existing laws.

For instance, questions will arise, as to whether it's reasonable for Lovable to hand this kind of power over to a customer. And, if their software is capable of detecting vulnerabilities, but allows the customer to proceed, is that reasonably responsible behavior on Lovable's part?

Then, there are tests regarding what their customers should reasonably be expected to understand. For instance, it might be tempting to compare this to gun liability laws, wherein manufacturers can disclaim responsibility if their guns are mishandled. But, here, what is the level of knowledge required to fully understand the risks—including the risk/cost of breaking a production build? And, is it reasonable that their customer should be expected to understand?

And, this even comes down to their marketing. If they are actively selling to novice customers, with the pitch that no expertise is required, then it may prove very difficult to pin the blame on those customers.

Attorneys would likely argue that Lovable can't have it both ways—selling to amateurs, then blaming their customers for being amateurs.

Disclaimer: I once played a lawyer in a 7th grade mock court. Oh, and I've been sued.

> including the risk/cost of breaking a production build

If the customer is deploying (“to prod”) they need to know enough to assess their own risks of breaking their software.

I’d want to see the text of the warning to customers before having an opinion on how in/sufficient it was.

So the approach is:

1. Blame the user because they didn't verify the app they built on your infrastructure meets the most basic requirements?

2. Then provide a tool that offers no guarantees and no definitions of what critical vs non-critical means.

3. And put the extra onus on users to run a "deep" scan when they intuit (somehow?) that there might be problems for which there is no hint?

4. All while telling users that critical issues are really bad but normal issues are... ok? I have no idea what they are from your writeup.

5. While selling better security for business and even better security for enterprise. Because security for everyone else isn't important!?

Is this supposed to be a roadmap to security antipatterns?

I see it as an opportunity to educate the builder community on importance of using the provided security tooling. What I'm asking users is to use tools while building. Our tools explain security in business terms and give people tools to bridge the technical gap. Is it always enough? No, there's no perfect tool or approach, there will always be space to improve. But as you can see, if apps continue to expose the data, the actual blame falls on us - and there's no intention to say. And we are taking it as an input to improve our tools, UX, auto-fix tooling, user messaging and have more ways for users to build secure apps.

I find this theory really odd. Wouldn't it make more sense to flip it around and have it maximally locked down from the beginning? You're providing essentially a Supabase abstraction. Why not make the abstraction secure from the beginning?

You need a framework for sensitive data collection/usage. Auto-fix does not seem like a comprehensive approach.

working on it!

do we need yet-another-framework (cue xkcd standards link) or do they actually need to support one or all of the many that already cover financial, medical and personal data?

This is a perfect example of selling a snake-oil solution (assuming most users are not tech-savvy) and trying to get away with "we warned them, but they chose not to act upon" attitude.

As Head of Security you are not doing a good job.

wait, didn't you see "The root cause in these apps was insufficent Row-Level Security, which is exactly what our scanning is built to catch."

you just need to buy Lovable Ultra

no, it's all in Free tier. You can even enable auto-fix, so that you don't even need to look at scanner findings anymore.

So microsoft used to let you know when updates - even scary security ones - were available but never make you take action. They've gotten way more aggressive and now you have to have specific versions or a set of DevOps skills to prevent them from regularly applying and restarting your system. Their clients are mostly like yours: non technical users of very powerful systems; why don't you force upgrade after a certain period, even if it breaks apps in order to secure them? It has to be because that's bad for your company's goals, i.e. security is important but below growth and usage.

You are right, I'm not happy about apps still leaking the data. For now, my message is to go and click the Fix button. I know it won't reach everyone, but I think it's important people hear it and do it. In the meantime, we are stepping up our game and taking this feedback super seriously. There will be a few releases that will definitely improve the security baseline of Lovable apps.

> these apps

I knew what to expect as soon as read that in the very first sentence. Classic blameshifting. Maybe show a little bit of humility and admission of fault, you know the qualities that make people( and companies) 'lovable' and make ppl look past your mistakes.

Companies with absoloutly no moat like lovable have to win hearts first. This cya blame user response makes me want to use that site even less. Bye.

Only with Loveable is this constant problem of row level security a thing, you ever think it’s the wrong approach?

> I personally believe that making security accessible is what leads to making software accessible.

When your entry point for building an app is an AI prompt, "making security accessible" seems wildly below the standard. The role goes from making it accessible to ensuring it, given that you are marketing to clients who can't.

If your users are less technical then I think it is irresponsible to allow them to make choices that would compromise security and the data of others.

If there is a vulnerability the customer should have two options: patch or take down my app. Customers should _not_ be able to decide to defer/skip security if they are not technical enough to understand the impact.

It is great though that these scans are free for your users.

An interesting detail missing here is that there are two types of scans: “quick scans” and “deep scans.” Quick scans run automatically whenever a user publishes a project, while deep scans must be triggered manually -- except for enterprise customers.

https://docs.lovable.dev/features/security#built-in-security...

We are moving this feature to all paid tiers soon. I agree that scanning on schedule needs to be available to everyone.

> If your users are less technical then I think it is irresponsible to allow them to make choices that would compromise security and the data of others.

Counterpoint: HN about the iPhone. FWIW, I agree with the statement above, but also suggest a developer account opening up developer flags is a reasonable gate.

(Not sure how else to avoid all the "developers" clamoring for non-public betas of iOS bricking their iPhones, as the same audience that would flip a bunch of dev toggles if available to everyone like developer mode in Safari then scream how Apple should have done more to protect them when their bank account is emptied.)

But not needing to know what you're doing as far as programming goes != not needing to know what you're doing as far as compliance/legal responsibility. Someone using a tool like this still needs to run their operation in a sane manner. Like, how much responsibility does Loveable shoulder here? We don't blame a car manufacturer for most car crashes. They, of course, try to design their cars to be as safe as possible, but the fact that they endeavor to make a safe car doesn't make it explicitly their fault if I'm driving blindfolded and careen off a cliff.

This is something that makes me roll my eyes... seeing people online talking about how everyone can just make their own version of w/e software now. As though running a software business is simply a matter making the computer screen light up in a particular way.

RLS can be really tricky to get right, even for an experienced developer.

It's one of the reasons I've avoided supabase (and postgrest) because I've found any non-trivial security implemented via RLS to be a lot more difficult to implement, audit and test than equivalent middleware in express, for example.

I think it's going to be a pretty tall order to expect AI systems to nail this, as it requires quite a bit of reasoning and business domain expertise- the things that LLMs are notoriously bad at.

We are training our agent and models to get really good at RLS. A lot of projects mentioned in the research are created with older models, unfortunately. Which means, a worse starting point compared to where the models are today. Yet, they have access to latest scanners which are also optimized and trained on good and bad RLS outcomes. Our ask today is to click Free Fix and do not ignore warnings (incl email and in-app notifications to builders). Enabling auto-fix is another great way to decrease risk of your app. Also, soon we will have gates against publishing of anything with Critical issues in it, available to all tiers.

When you note a security issue like this, why wouldn't you automatically apply it?

If your terms of service can say, "When there's a data breach, it's technically your responsibility", I'm sure it can say, "When we detect a security issue, we'll push a fix without waiting for your OK."

in many cases, it's hard to understand and know is something is by design or by mistake. We are looking into having a path to take down apps that grossly violate privacy and data protection. It's a bit tricky legally so we need to find a good balance. Our thinking is so far: notification with ask to fix, grace period, if no action and no improvement - soft block until issues fixed.

If security is a key part of the product why is it left optional and up to the discretion of the (presumably non-technical) user?

I thought the purpose of vibecoding platforms like Lovable was to put guardrails in place and put non-technical people into the pit of success. But apparently not?

the purpose of Lovable is to increase signups, usage and other metrics that drive valuations. If security was a critical component the free usage tier is the ONE place you COULD force-apply these barriers without your customer having a valid complaint!