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