Igor here, Head of Security at Lovable. Thanks to the Crissy Field team for their work.
The root cause in these apps was insufficent Row-Level Security, which is exactly what our scanning is built to catch. We scan every app automatically before publish and offer a deeper SAST scan, both free for all users. When we flag findings, users can select “Fix” and Lovable will help resolve them. They can also enable auto-fix, which resolves security findings in the background, and block publishing entirely when there are critical findings.
When an app has end users, security is a key part of the product. That’s why we keep investing in making security tools better and easier to use, taking on as much of the security load as we can and fixing more issues automatically.
I personally believe that making security accessible is what leads to making software accessible. We’re committed to both.
> the people affected here are end users who did not action provided findings.
7500 site operators failing to "action provided findings" seems like a systematic failure on your part and you should accept more responsibility for it. I'm guessing users find the security warnings unclear, confusing, or meaningless. Don't allow users to publish apps if you know they leak private data. Work on educating users and make the apps be built securely the first time.
Surprisingly, for many users it's the fear that the fix will break production. And no matter how good are findings or warnings, or modals blocking publish, some apps will still do it.
And that's why I believe auto-fix will solve a lot of problems in this space. We are now training our auto-fix to be very considerate and avoid breaking changes, trace back to user prompts and intent. The goals is to make it widely adopted and one day (soon!) turn on by default.
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.
[−]FromTheFirstIn · 2026-11-15 Sun 00:04 UTC ·
link
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.
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.
[−]FromTheFirstIn · 2026-11-15 Sun 15:20 UTC ·
link
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
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.
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.
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.
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.
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.
Isn't Lovable in this case more analogous to a consultancy to whom customers outsourced their website builds — meaning the customers, not Lovable are 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…
If the consultancy delivers vulnerable software to the customer, the customer would most likely sue the consultancy for any damages they incurred. Especially if there is a maintenance contract, where the consultancy handles any security upgrades etc that are necessary.
# 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.
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.
The controller/processor relationship is very clearly described as part of the GDPR and there is little doubt in my mind that both of these parties jointly and separately carry responsibility here.
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.
Any data fetched during the analysis was deleted long ago, though you’ll have to take my word for that. Only metadata was retained.
That said, I fully agree that no one can say for certain whether anyone else collected this data or what happened to it afterward.
[−]unclebucknasty · 2026-11-15 Sun 00:43 UTC ·
link
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?
So, this even comes down to their marketing. If they are actively selling to novice customers, with the pitch that no expertise is required, then customers may argue that they were "set up", and 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 my company was once sued.
Although already mentioned in the research report, the following links show that Lovable explicitly targets non-technical customers, stating that no technical expertise is required:
This fundamentally changes the startup equation:
- No need to convince a developer to join before validation.
- No delays from back-and-forth translation between business and tech.
- Immediate product iterations, turning feedback into new features
within hours.
With Lovable, non-technical founders cut months of friction and focus
entirely on product-market fit, rather than struggling to find a
development team.
All you need to kick off your vibe coding journey is an AI-powered
no-code builder (like Lovable). As long as you can describe what
you're looking to build, you can build it.
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?
It's so interesting how you've created a nice ecosystem where you're not responsible for the security problems but at the same time your users are meant to trust you to take care of that. We really need to change the laws around this.
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?
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.
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.
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.
You could've just written "these apps" and left it at that. Using this to pitch your product features is diabolical.
Only with Loveable is this constant problem of row level security a thing, you ever think it’s the wrong approach?
[−]shepherdjerred · 2026-11-15 Sun 03:54 UTC ·
link
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.
> 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.)
The Lovable class of tools is fascinating as the value prop is explicitly you do not need to be a developer, you do not need to know what you are doing. I think that makes the responsibility clear in a way the iPhone does not.
[−]jamesyoungquist · 2026-11-15 Sun 16:14 UTC ·
link
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 goes. 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.
[−]claytongulick · 2026-11-15 Sun 04:07 UTC ·
link
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!
When an app has end users, security is a key part of the product. That’s why we keep investing in making security tools better and easier to use, taking on as much of the security load as we can and fixing more issues automatically.
I personally believe that making security accessible is what leads to making software accessible. We’re committed to both.
You can read more about our approach: https://lovable.dev/blog/find-it-fix-it-ship-it
7500 site operators failing to "action provided findings" seems like a systematic failure on your part and you should accept more responsibility for it. I'm guessing users find the security warnings unclear, confusing, or meaningless. Don't allow users to publish apps if you know they leak private data. Work on educating users and make the apps be built securely the first time.
And that's why I believe auto-fix will solve a lot of problems in this space. We are now training our auto-fix to be very considerate and avoid breaking changes, trace back to user prompts and intent. The goals is to make it widely adopted and one day (soon!) turn on by default.
This is the new future, I'm just not sure I want to be part of it.
"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.
Thanks for joining us here directly.
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 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.
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
> 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'
As opposed to?
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.
To be fair, one can harbor a fear of updating after bad experiences with entirely unrelated software.
unacceptable! it's all about the vibes!
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?
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…
The controller/processor relationship is very clearly described as part of the GDPR and there is little doubt in my mind that both of these parties jointly and separately carry responsibility here.
Any data fetched during the analysis was deleted long ago, though you’ll have to take my word for that. Only metadata was retained.
That said, I fully agree that no one can say for certain whether anyone else collected this data or what happened to it afterward.
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?
So, this even comes down to their marketing. If they are actively selling to novice customers, with the pitch that no expertise is required, then customers may argue that they were "set up", and 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 my company was once sued.
Although already mentioned in the research report, the following links show that Lovable explicitly targets non-technical customers, stating that no technical expertise is required:
https://lovable.dev/blog/what-is-vibe-coding
https://lovable.dev/blog/2025-01-30-why-non-tech-founders-no... https://lovable.dev/founders https://lovable.dev/vibecodingIf 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.
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?
It's so interesting how you've created a nice ecosystem where you're not responsible for the security problems but at the same time your users are meant to trust you to take care of that. We really need to change the laws around this.
As Head of Security you are not doing a good job.
you just need to buy Lovable Ultra
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.
You could've just written "these apps" and left it at that. Using this to pitch your product features is diabolical.
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.
https://docs.lovable.dev/features/security#built-in-security...
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.)
The Lovable class of tools is fascinating as the value prop is explicitly you do not need to be a developer, you do not need to know what you are doing. I think that makes the responsibility clear in a way the iPhone does not.
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.
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.
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."
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?