Or just the natural consequence of adopting "move fast and break things" from top to bottom for 20 years, a house-of-cards methodology that was destined to fall in on itself whether or not such models ever arrived.
Formal verification doesn't solve all the problems, but alongside concerns like correctness, restrained surface area, supply chain awareness, treating PII as toxic waste to avoid rathee than treasure to collect can leave projects/orgs in a much better place than they let themselves get too.
This is one of the reasons anthropic nerfs their models. They want you to have an enterprise contract with some spend before they’ll allow you a couple of seats on cyber models, which you need since attackers are much more nimble with ablated open weights models.
As a side note to the "nerfing", I worked with a journalist on the analysis, and she wasn’t comfortable running `curl` on the command line. So she asked the AI to do it -- but it refused, citing concerns about cyber abuse.
On the one hand, that’s kind of encouraging. On the other, it feels like the unskippable “don’t copy this movie” warning on a legally purchased DVD -- the one that gets removed from pirated versions.
I can't state my disdain enough for the rabid, careless advancement of AI, and all the bros that keep telling me to catch up or fall behind, while they are actively causing harm to the hundreds of thousands, or millions of users they have, without care or consideration.
Nearly two decades of experience learning how to build safe, performant software, to be replaced by this shit.
We don't care about people, our customers anymore. We actively harm them for profit. This is such a garbage industry now.
The idea that companies invested in "safe, performant software" before AI is laughable. Tech companies have never cared about the customers beyond their effect on KPIs.
Companies never cared, and most engineers didn't care much either, at least not directly. But a lot still cared to cover their ass and try to do things correctly the first time to reduce future work and headaches. Now that it's all just a few prompts away "Who cares? Ship it now, if it's broken we'll just have Claude fix it later."
>I can't state my disdain enough for the rabid, careless advancement of AI, and all the bros that keep telling me to catch up or fall behind, while they are actively causing harm to the hundreds of thousands, or millions of users they have, without care or consideration.
Have you ever considered that the people who are pro-AI are not a monolith, and that it can be simultaneously true that you should absolutely be learning how to effectively and safely use LLMs in engineering workflows, while it is also true that there are people who are using them very unsafely?
Beig opposed to learning how to use AI correctly because some people use it recklessly is like being opposed to learning AWS in 2015 because some people left sensitive data in open S3 buckets.
Do not confuse negligent misuse of the tool for the value proposition of the tool itself.
Re-read my post before quoting it and getting defensive. I'm not anti-AI, I use Claude daily, partly because that's all the industry is now, partly because it can be an amazing tool.
I'm furious about slop-shovelling profit-driven development that actively causes harm to people. And the lack of care for, or outright disdain of customers, specifically fuelled by a misuse of AI, and the people telling me to get used to this, the people telling me to stop reading my own PRs, the people telling me this is just how it is now. When we all know that doesn't have to be true.
Just bide your time until there are some absolutely catastrophic breaches like what is happening in Japan right now on a daily basis, and then people and legislators will slowly start demanding accountability.
I just don't see any grassroots movement advocating for responsible software development winning out with a demographic that can't even unionize for their own self benefit.
Bad take. That's impossible in our society. I wouldn't get updates from my child's kindergarten. I wouldn't be able to use public transit. I can't access my bank. I can't communicate with my family, friends, spouse, work network.
We don't have an option. Which is why a lack of care for users is abhorrent.
Keeping _more_ of your data private is not impossible. It won't necessarily be the most comfortable thing, as tradeoffs will be made, but you can claw back quite a bit of privacy if that is important to you.
Of course, but that's not what the person I was responding to said. They blamed people for trusting services (many of which) they don't have an option to opt out of.
And this whole thread is just proving my point by blaming people and customers for the mistakes of technology companies.
Lovable is not the same as using your bank account or your health insurance.
You create a website and put it on the internet and maybe even host sensitive data and information.
This should only be done if you know what you are doing and if that’s not the case and you haven’t read the terms of service it’s mostly your fault that you trust any company on the web especially those coked out VC backed startups.
If you invest more money you’ll get a good website and your data will be taken good care of by human professionals.
It’s simple as that.
If there are passports in these dumps, Lovable is obviously being used for sites that _are_ as serious as your bank account or health insurance. That's exactly the problem birdsong's bringing up in this thread.
If it were only used for prototypes and blogs, who cares. But it's being used by _real businesses_ that don't give a shit about security.
I specifically chose banks and health insurances specifically because you can not get around using their websites and online services in your daily life.
For all other services: is it really necessary to give them your passport info on the internet ?
Customers are absolutely without blame here. They have no way of knowing which parties are and which parties are not running a tight ship. Every e-commerce store already handles your private data, how will you ensure that across all of those each and every one is going to be careful with your data? I'm not the most active online shopper in our household by a long shot and yet I've had two reported breaches in the last year alone, one a specialty welding store, the other a store for home automation products. Now, both of these are 'niche' and probably don't have a security budget to match their responsibilities. Even so I would have expected some basic precautions and that trust seems to have been misplaced. I expect each and every website where I've ever filled out a form to be hacked sooner or later. Nobody seems to do anything about blast radius reduction, which would be trivial. But marketing wants to keep the last 20 years of purchases live so they can send out some more spam, when what they really should do is move those records to cold storage for tax compliance only the moment the package is delivered.
My perspective is to figure out how to shape the way we use AI to show the right way to use it. This comes from a place of caring about the software and its users.
I strongly believe that when used properly, AI can remove a lot of overhead that comes with writing the code (from both a critical thinking standpoint and physically it actually takes a lot more time than people realize to manually type code). You can focus on the design and have your team much more integrated in the designs and specifications of things without it being a slog to document the damn thing.
If I can go off and write up a draft and get feedback from my team in a day instead of in a week, I think that's fine. We can collectively walk through and use everyone's domain knowledge to correct details. Once everyone is onboard with the spec, I can feed that into a model to progressively do small changes rapidly but in such a way that's still manageable and reviewable for myself and the rest of my team.
If I go off and merge 45000 lines of code into main: fucking fire me and my whole team that approved that.
As with all new things that have extreme views on either side (AI is complete shit versus AI is the second coming of Christ in this case), there's generally a middle ground in between that we can collectively correct toward.
Oh I agree! However, while they do brag about 30,000 PRs per day, they don't state what products these apply to.
I suspect for their public facing products (i.e., the claude ecosystem, which is like four products), the review process is much more rigorous, and the PRs merged in per day is likely much much lower.
A few things about their post: they're doing trunk development on a mono-repo. With their tool, Antique, instead of having branches, they just merge in stacks of commits, which they call "Change Requests". I have to wonder if their engineers have the models running and don't even realize the models are putting up a change request and if that's contributing to the high number.
Additionally, I would guess that a lot of the code merged into that mono repo is for experimental projects or other internal tooling that is in prototyping stage.
Amen. It's kind of ironic that the same tools that are better at finding vulnerabilities than humans (e.g. https://www.sshhole.com) are creating a proliferation of shit-code and shit-sites full of vulnerabilities faster than anyone can keep up with.
Railway got hit by pretty much this a few days ago. Attacker likely used abliterated models, stolen keys, ~$740k in AI charges. If it happens to them, random Lovable apps are easy targets.
How is that the same thing. Lovable didnt get hacked.. Also hint, there's nothing scary about ablit models, they dont increase someones capability to hack something with AI just reduce annoying refusals, purely ergonomic.
I can confirm that no advanced hacking techniques were used, and anyone with a moderate understanding of how the web works will be able to reproduce the results.
The initial idea behind the analysis was to start with the most basic setup and then move on to more sophisticated attacks. We never reached that second part, as so much sensitive data was already out in the open.
The bar being vastly lowered is the qualitative difference that AI pushers don't seem to appreciate. At their root, many of the issues we currently see with AI are really cultural/procedural issues that have existed in the industry for a long time, but AI has dumped napalm on the dumpster fire and the neighborhood is now catching fire.
Hi, I’m the author of this blog post. I submitted it to HN two weeks ago, but it didn’t gain much traction, so I’m glad to see it resubmitted. Happy to answer any questions, though I think the situation is fairly self-explanatory.
Technically speaking, is the "leak" or "vulnerability" in Loveable's architecture or in the Supabase database integration?
If the real issue is with Supabase then it needs further investigation as several AI tools use Supabase as standard now, not to mention many opensource projects.
Supabase loves RLS, this is just poorly implemented RLS on the vibe-coder's side. It's too hard to reason about and not well exposed or debugged on Supabase's or Lovable's interfaces.
The core issue is how easy it is to misconfigure Supabase (much like Firebase) due to the data security relying on RLS policies. It's such a poorly designed system and so easy to get wrong, and it's clear here that Lovable's AI generator is getting it wrong.
Even when you do get Supabase's RLS policies correct, Supabase still doesn't offer a way to rate limit these tables. i.e Even if the data is secure, an attacker can overwhelm the database instance with big query in a simple for-loop and it's a constant source of issues in the Supabase Discord. There's no server in between that can enforce any rate limits. The whole "query the database from the client" has so many security pitfalls.
It’s Lovable using Supabase incorrectly, so Lovable is rightly to blame.
To add some nuance: Supabase’s security controls aren’t the simplest to work with and have been a source of confusion -- and data exposure -- for years. But Lovable markets its product specifically to people who, it claims, don’t need that technical knowledge. That sets the expectation that the user doesn't have to worry and thatLovable will get Supabase access controls right.
It's incredible how little understanding the average person has about data, privacy, and security.
Allowing anyone to build and host a public app without a basic understanding of these things is like letting people fly a passenger plane without a license.
> Allowing anyone to build and host a public app without a basic understanding of these things is like letting people fly a passenger plane without a license
Is it now? How many hundreds of people have died as a result? How much infrastructure was destroyed?
I get the point you're trying to make, but computer security as a field has already a big problem with maximalist mindset, and it doesn't help in keeping systems of consequence actually secure and people safe from danger.
Allowing anyone to design, install, and maintain the plumbing, heating, and electricity of your house without a basic understanding of these things is like...
I strongly disagree with the second part. Building public app should not require same level of skill as flying an airplane. Not even the same as getting a driver license. It had to be simple, secure and compliant.
The problem are product managers and engineers who build things like Lovable, that are not secure by design. Those products have no right to exist, but their alternatives could exist and let their users focus on what matters, instead of paying web development tax.
When the number of things you can possibly build is infinite and LLMs are not guaranteed to catch security issues you need some skill or you constrain what can be built to a subset. I.e. build a platform where users own their data and it is partitioned and the slop runs atop that. Similar to running the slop on an airgapped laptop.
The plane analogy would be selling tickets to passengers. Who then don't need a pilot license to get somewhere.
I’ve been mentioning it for years, but data, privacy, and security do not matter to most people, despite them saying so. Personally I operate assuming that my IDs, passport and etc. have already been leaked at some point. So, if someone says my PII has leaked once again, I’d just shrug and move on.
When Equifax thing happened, there was basically no repercussions. And that’s the only data breach I recall being in the news cycle for more than a week. Everything else has just been a blip since then. Also as there were no real repercussions other than some fines, companies took it as a signal that nobody cares (rightfully).
I've got a similar viewpoint. I'm always surprised when someone freaks out about their credit card info being leaked, for example. At least in the US, you're almost always guaranteed to get the money back ASAP for any unauthorized charges and a new credit card sent to you (overnight if you need it, for higher-end cards). So why are people so afraid of their credit cards being "stolen"?
Folks are blaming AI, and that's certainly part of it (folks without knowledge and experience can now build polished apps, though there were still plenty of "WTF" security breaches before AI), but I feel like the only thing that can fix this are real, stiff liability consequences.
The defects listed in this report didn't require some complicated 0-day exploit chain - they were just sensitive data stored without any authentication at all, in a database that anyone with Internet access can view. In other words, it would be the equivalent of a company like Public Storage leaving all of its storage units with no locks on them at all.
Affected users should be able to sue for a lot in these basic security failures. And obviously for many of these small websites, the potential damages would quickly bankrupt the site owners, but that's the point. People would think a lot more carefully about how they protect sensitive data if there were real negative consequences for their failures.
I agree that AI is not necessarily at the core of the problem.
To me, the issue is Lovable’s borderline reckless marketing: repeatedly claiming that “everyone” can build a website “without any technical knowledge” (verbatim from their website), while disclaiming all liability for bugs in their terms and placing responsibility for security on their customers.
Customers who hear day in, day out that “software is solved” and buy into Lovable’s narrative may simply have no idea that they could face substantial fines for privacy violations.
EU citizens can sue. It's not easy in every EU country, and ot differs whether you will be compensated.
But in all cases, under GDPR, the one having the data breach is required to act. If they fail, there's steep fines, often proportional to your revenue. It will hurt the business.
IANAL, but I've had several hosting companies. And while most situations where a customers' site is hacked and/or their data leaked, is clear and not the hosters' responsibility. That hoster does have an obligation to provide good tooling (i.e. ssh, not telnet, sftp, not ftp) and to promote good behaviour (i.e. not allowing the backup system to write the backups to public hosted directories). Or else can be held (partially) responsible for breaches.
Lovable has a responsibility, and, as you pointed out in your article, their proposition of "building apps without technical knowledge" (my words), might make theirs to be more than just putting lines in a EULA to waver that responsibility.
Sorry, I was flippant in my previous comment -- they SAY they can’t be sued. I’d hope those “non-technical founders” wouldn’t be left out in the cold and that Lovable would be held liable as well.
That's not a run race. They are a processor and this definitely was on their watch. Both controller (the website owner) and the processor and sub-processor (Lovable, Supabase) all have pretty clear joint and individual responsibilities here and all of them have failed to greater or lesser degree. The Controller may even be in the better position of the three.
For example, if you try to access a table named "secret" that doesn’t exist, Supabase might return a hint saying, "Perhaps you meant the table 'public.super_secret'."
Thanks for volunteering that information, I guess.
The hint is not a problem if you use the PostgreSQL default of deny for every table, Supabase is migrating to this default https://github.com/orgs/supabase/discussions/45329. If the defaults are in place even if you see the table name on the hint it will be inaccessible (fails immediately before RLS checks).
Note that the hint is added by PostgREST and it was introduced at a time where users manually typed table names, causing them to report malfunctions on typos. These hints are not that as necessary anymore so they're usually disabled via config[1] and will likely be dropped on a next version.
If your goal is to onboard nontechnical users quickly and not have to deal with them churning because they have to deal with thinking about those pesky "security rules" before they can get a working app, it totally makes sense that you would do this, especially if you just drop a get out of jail free "well, it's the end user's fault for not configuring their app securely" in your T&C.
Somehow it's okay to simultaneously set a golden path to less secure software to support your hockey stick growth model and then turn around and blame end users when it all goes wrong.
The idea was that RLS (Row-level security) would be enabled on any tables exposed to the data API, and RLS was “heavily encouraged” to be turned on by default in the dashboard, and RLS was on by default since at least 2025. Tables require explicit RLS policies to be accessible by the data API, so by default it’s not open like that anymore.
In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.
Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.
I think the idea is to use edge functions against the database with RLS helping with low level access control, but it's still a tough design pattern to hold people accountable to. May as well as write the whole thing in a backend and just skip Supabase's API/RLS entirely.
The whole proposed benefit of their "query the database from the client" concept was the speed and ease of development. If you need edge functions (cost per invocation too, mind you) to make this happen, it's just a terrible design in general.
I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.
Have you looked at PocketBase? If I understand correctly it solves both of these to some degree and from my perspective pretty cleanly. Building a self-hosted, OS version of Firebase and SupaBase was the inspiration I believe.
There is nothing wrong with this. It's no different from unauthenticated API routes to get public information. The issue is when somebody doesn't use RLS correctly.
Any tables created before the defaults put in place are of course still subject to the wide open defaults, because they would risk break existing users apps if they back-ported those.
The amount of misconfigured supabase out there is astounding. And I'm not just talking about your mom's friend who wants a mahjong social network site. Companies backed by sand hill road VCs to the tunes of 10s of millions of dollars expose keys, don't have rls, set anon envs that are really full admin keys, don't rotate keys, etc.. the list goes on. It's wild.
It's a shame that making things easy to use has typically meant the user gives up control/hosting capabilities and generally gets less security out of the box. You're probably right about Supabase, that they made that tradeoff explicitly, but they have more demand than they keep up with now and finally seem to be course correcting toward more secure defaults. They apparently believe this will make onboarding their users more difficult (this is a false dilemma IMO).
People who don't get Postgres and RLS implement it sloppily and you inevitably get cases like this. You can put that on the user but I think platforms have a higher bar here to create experiences or interfaces where the easy path is the most secure one. There are obviously other parts of the process that can be leaky beyond beyond just the database config so the app architecture needs to make the system cohere together securely and I just don't feel like the existing platforms are fully up to the task.
The vibecoding tools like Lovable, bolt, v0, replit, base44 don't really attempt to be overtly transparent because that's not the point. They all sell the idea of a concierge service but that only works if the experience is actually "luxury" which in this case means you can trust in a guaranteed basic level of data privacy.
Seeing as this is reported by a German organisation about a Swedish company: has this been filed with the authorities under the GDPR?
Any details on whether (national) data protection authorities have picked it up and warned the companies and people in violation?
The analysis was conducted with the assistance of a lawyer specializing in data protection. A deliberate decision was made to share the dataset with Lovable so they could contact their customers and have the database access issues resolved.
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.
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 web developer. I suppose next I might hear something like never define your own table schemas...
At least with "lovable", people knew what they were getting into when they sent their PII to an AI slopped project.
But unfortunately, it’s not always this transparent. In the US, doctors (particularly PE owned ones) often use AI in their backend in one form or the other. In one case, I observed their transcription service was using some LLM to help process data into medical record.
In other cases, your data may even be processed/leaked/trained without your explicit consent through a third party vendor that doesn’t interact directly with doctors office (physician office -> order sent to pharmacy -> pharmacy uses LLM to process data).
This is at least the case for the insidious CVS/Caremark conglomerate.
Each psychotic vibecoder making 50 slop projects on an account. Also probably counting demo projects. Idk, if I had to bet against any company it would be lovable.
But they have tons of VC money so they'll get aquired by someone in the incestuous circle of SV investors.
non-tech founders, small businesses, non-tech freelancers, everyone on budget who cannot afford hiring a dev and a designer and who wants something fancier than classic CMS.
Those people can very easily make a website all on their own using the latest models. It will be cheaper and higher quality.
Yes you will need SOME technical knowledge. But people are just lazy. Everyone can learn this stuff. Just ask any anthropic model how to deploy a website, it’ll tell you.
These are canaries in the colemines. Platforms need better defaults, deny-by-default DBs, least-priviledge API, automated auth tests, etc. Basically make insecure deployments difficult with AI generated code.
I strongly agree! I think occurrences like these are going to be common when using platforms where we assume that creators will run security checks after the fact. In another comment here, lovable is say that app creators are culpable because they didn't take action to fix security issues.
I'm the creator of Skape - an app building platform where the security is baked into the platform itself. Login and sharing data with other users all happens in the platform. This doesn't mean "your app shows its own UI and then feeds username/password to a login service" - I mean that Skape's UI handles login, and then while you use your app, Skape routes your data requests to your database. The app is treated as untrusted by the platform, which means app creators and users have to worry a lot less about the security of vibe coded apps.
I think that this is a better approach to security that will allow users to trust the software on the skape platform to a higher degree.
It's not an appropriate solution to for AI vibe coding IMO. It's too complex. People without a technical background need a simpler abstraction than RLS.
I wonder what will stop or at least force this wave of individual creators to think a bit further. If I leak data at my job it's a massive deal. Like stop working, start calling people and light a cigarette type deal.
Like mentioned elsewhere in this thread, there are doctors vibe coding shite and sending private medical data to Anthropic's servers, probably without even checking the "don't use for training lol" checkbox. Thousands of passports, invoices, whatever, are rn available on the open internet. People posting private company data on PUBLIC github repos (dealt with 2 such cases lol).
These individuals aren't held to the same standards, and right now nobody is enforcing the rules on them.
And maybe that's fine. Maybe we don't want to stifle innovation. But if my passport ends up on the dark web and I get identity theft'd, then I'd be pissed. There are REAL consequences.
Lovable provides tooling, the responsibility and liability is of the client that uses it to generate a system. It doesn't look like a vulnerability of Lovable itself
although I don't use it enough to know the specific details of how it is infrastructured. But since the promise is that it writes any code that you want, it's logical that the arbitrary code is not a property of the code generating tool but of the user that generated the code!
I cannot wrap my head around jacquesm's insistence that this is a breach.
Can someone please correct me if I'm wrong here, but isn't the article claiming that all data was publicly accessible with a read-only API key, also publicly shipped in each site?
Unless I'm missing something, no amount of digging into *published* data is a breach of anything. The act of publishing it is the leak, not the consumption.
While you are technically correct, in practice the democratizing of a tool that can be consequential in leaking your private information should come with stronger safeguards and educational opportunities for those who aren’t well versed in technology.
Lovable lets you do stuff without even understanding semantically what API or API Key means and how it can or should be used.
Moving too fast and putting the onus at the user is a bit shady.
I think it really depends on the data itself and jurisdiction. There's very real chance just having more data than you need to prove the exploit exists could open you up for potential legal liability (especially if the data itself is sensitive). Imagine a situation where the researcher gets compromised after the fact with sensitive data lingering around on their machine.
Hasn't there been cases where people got charged for unauthorized access to computer system by simply changing some identifier in the URL?
Data being technically accessible doesn't mean it's meant to be accessed by anyone.
If I understand this right, this is the equivalent of leaving a house key hidden under the doormat. Just because it can be easily found doesn't mean anyone's just legally allowed to use it.
Well, there was. But inputting or editing a url is akin to submitting a form or a get request, if somebody doesn't know how to not get breached by such events, they have no business running a website with delicate data
Any unauthorized access to a computer system can be criminal. If you find some way to access data that you're clearly not supposed to see, it may be a criminal offense. I don't know how much weight it has whether the software provider has been negligent themselves, I assume it depends on the jurisdiction.
I went looking for any recent cases, here's one example[0] of a software provider being negligent, yet the security researcher got the axe:
> In the appeal proceedings on Monday, Aachen Regional Court adopted the assessment of Jülich District Court that access to the secured database constituted a criminal offense. Trial observers from the Chaos Computer Club reported that the court did not care how the defendant had obtained the password. The password was not easy to guess or publicly known, making access a criminal offense.
When I did some hacking myself ~15 years ago, I looked at these kinds of cases and learned to not touch any system that doesn't have a bounty program. Otherwise you put yourself at a lot of risk. Bug bounty programs prohibit access to sensitive data - so if you were to download data like it was done in the article, you might not only not be compensated, but also the company may decide to report you. No company wants to deal with leaked sensitive data, it's a huge business risk for them, so they may take more drastic measures in these cases.
200 comments
[ 0.20 ms ] story [ 14.0 ms ] threadImagine frontier abliterated models running at 2,400 TPS finding all these issues rapidly on web apps like this.
You are not ready security-wise when these models get faster. ("Formal verification" won't save you either)
Formal verification doesn't solve all the problems, but alongside concerns like correctness, restrained surface area, supply chain awareness, treating PII as toxic waste to avoid rathee than treasure to collect can leave projects/orgs in a much better place than they let themselves get too.
Long way to go from here though.
On the one hand, that’s kind of encouraging. On the other, it feels like the unskippable “don’t copy this movie” warning on a legally purchased DVD -- the one that gets removed from pirated versions.
It seems to punish the wrong people.
Nearly two decades of experience learning how to build safe, performant software, to be replaced by this shit.
We don't care about people, our customers anymore. We actively harm them for profit. This is such a garbage industry now.
Now you'll be at least 50% slower and likely fired if you care, because caring means understanding the code.
Have you ever considered that the people who are pro-AI are not a monolith, and that it can be simultaneously true that you should absolutely be learning how to effectively and safely use LLMs in engineering workflows, while it is also true that there are people who are using them very unsafely?
Beig opposed to learning how to use AI correctly because some people use it recklessly is like being opposed to learning AWS in 2015 because some people left sensitive data in open S3 buckets.
Do not confuse negligent misuse of the tool for the value proposition of the tool itself.
I'm furious about slop-shovelling profit-driven development that actively causes harm to people. And the lack of care for, or outright disdain of customers, specifically fuelled by a misuse of AI, and the people telling me to get used to this, the people telling me to stop reading my own PRs, the people telling me this is just how it is now. When we all know that doesn't have to be true.
I just don't see any grassroots movement advocating for responsible software development winning out with a demographic that can't even unionize for their own self benefit.
Only counterpoint is we have very well functioning unions in Norway for engineers.
But yeah, I don't see grassroots movements winning anywhere. Not even here.
https://en.wikipedia.org/wiki/Norwegian_Society_of_Engineers...
https://en.wikipedia.org/wiki/Tekna_(Norway)
We don't have an option. Which is why a lack of care for users is abhorrent.
And this whole thread is just proving my point by blaming people and customers for the mistakes of technology companies.
If you invest more money you’ll get a good website and your data will be taken good care of by human professionals. It’s simple as that.
If it were only used for prototypes and blogs, who cares. But it's being used by _real businesses_ that don't give a shit about security.
For all other services: is it really necessary to give them your passport info on the internet ?
I strongly believe that when used properly, AI can remove a lot of overhead that comes with writing the code (from both a critical thinking standpoint and physically it actually takes a lot more time than people realize to manually type code). You can focus on the design and have your team much more integrated in the designs and specifications of things without it being a slog to document the damn thing.
If I can go off and write up a draft and get feedback from my team in a day instead of in a week, I think that's fine. We can collectively walk through and use everyone's domain knowledge to correct details. Once everyone is onboard with the spec, I can feed that into a model to progressively do small changes rapidly but in such a way that's still manageable and reviewable for myself and the rest of my team.
If I go off and merge 45000 lines of code into main: fucking fire me and my whole team that approved that.
As with all new things that have extreme views on either side (AI is complete shit versus AI is the second coming of Christ in this case), there's generally a middle ground in between that we can collectively correct toward.
So the very company you're (possibly) using to "remove a lot of the overhead" is doing what you think is fireable! That's the irony!
¹https://www.anthropic.com/research/redesigning-source-contro...
I suspect for their public facing products (i.e., the claude ecosystem, which is like four products), the review process is much more rigorous, and the PRs merged in per day is likely much much lower.
A few things about their post: they're doing trunk development on a mono-repo. With their tool, Antique, instead of having branches, they just merge in stacks of commits, which they call "Change Requests". I have to wonder if their engineers have the models running and don't even realize the models are putting up a change request and if that's contributing to the high number.
Additionally, I would guess that a lot of the code merged into that mono repo is for experimental projects or other internal tooling that is in prototyping stage.
- They are an easy target, they don’t need any sophisticated hacking knowledge (article mentions inspecting network calls in browsers).
- There tons of those, and more created everyday. For the average user, they don’t know what they are using, or how risky it can be.
The initial idea behind the analysis was to start with the most basic setup and then move on to more sophisticated attacks. We never reached that second part, as so much sensitive data was already out in the open.
If the real issue is with Supabase then it needs further investigation as several AI tools use Supabase as standard now, not to mention many opensource projects.
Even when you do get Supabase's RLS policies correct, Supabase still doesn't offer a way to rate limit these tables. i.e Even if the data is secure, an attacker can overwhelm the database instance with big query in a simple for-loop and it's a constant source of issues in the Supabase Discord. There's no server in between that can enforce any rate limits. The whole "query the database from the client" has so many security pitfalls.
There are many BAD databases, choosing the wrong one still makes the owner responsible.
To add some nuance: Supabase’s security controls aren’t the simplest to work with and have been a source of confusion -- and data exposure -- for years. But Lovable markets its product specifically to people who, it claims, don’t need that technical knowledge. That sets the expectation that the user doesn't have to worry and thatLovable will get Supabase access controls right.
Allowing anyone to build and host a public app without a basic understanding of these things is like letting people fly a passenger plane without a license.
Is it now? How many hundreds of people have died as a result? How much infrastructure was destroyed?
I get the point you're trying to make, but computer security as a field has already a big problem with maximalist mindset, and it doesn't help in keeping systems of consequence actually secure and people safe from danger.
You can watch DIY channels on YouTube where homeowners explain their methods.
In particular, they are vibe-rehabbing entire homes.
The problem are product managers and engineers who build things like Lovable, that are not secure by design. Those products have no right to exist, but their alternatives could exist and let their users focus on what matters, instead of paying web development tax.
The plane analogy would be selling tickets to passengers. Who then don't need a pilot license to get somewhere.
When Equifax thing happened, there was basically no repercussions. And that’s the only data breach I recall being in the news cycle for more than a week. Everything else has just been a blip since then. Also as there were no real repercussions other than some fines, companies took it as a signal that nobody cares (rightfully).
The defects listed in this report didn't require some complicated 0-day exploit chain - they were just sensitive data stored without any authentication at all, in a database that anyone with Internet access can view. In other words, it would be the equivalent of a company like Public Storage leaving all of its storage units with no locks on them at all.
Affected users should be able to sue for a lot in these basic security failures. And obviously for many of these small websites, the potential damages would quickly bankrupt the site owners, but that's the point. People would think a lot more carefully about how they protect sensitive data if there were real negative consequences for their failures.
To me, the issue is Lovable’s borderline reckless marketing: repeatedly claiming that “everyone” can build a website “without any technical knowledge” (verbatim from their website), while disclaiming all liability for bugs in their terms and placing responsibility for security on their customers.
Customers who hear day in, day out that “software is solved” and buy into Lovable’s narrative may simply have no idea that they could face substantial fines for privacy violations.
But in all cases, under GDPR, the one having the data breach is required to act. If they fail, there's steep fines, often proportional to your revenue. It will hurt the business.
E.g. here's what a ditch citizen can do and expect https://www.autoriteitpersoonsgegevens.nl/en/themes/security...
IANAL, but I've had several hosting companies. And while most situations where a customers' site is hacked and/or their data leaked, is clear and not the hosters' responsibility. That hoster does have an obligation to provide good tooling (i.e. ssh, not telnet, sftp, not ftp) and to promote good behaviour (i.e. not allowing the backup system to write the backups to public hosted directories). Or else can be held (partially) responsible for breaches.
Lovable has a responsibility, and, as you pointed out in your article, their proposition of "building apps without technical knowledge" (my words), might make theirs to be more than just putting lines in a EULA to waver that responsibility.
This was supposedly fixed on October 30, but there are reports floating around that for existing projects, the defaults still apply
https://docs.postgrest.org/en/latest/references/errors.html
For example, if you try to access a table named "secret" that doesn’t exist, Supabase might return a hint saying, "Perhaps you meant the table 'public.super_secret'."
Thanks for volunteering that information, I guess.
Note that the hint is added by PostgREST and it was introduced at a time where users manually typed table names, causing them to report malfunctions on typos. These hints are not that as necessary anymore so they're usually disabled via config[1] and will likely be dropped on a next version.
[1]: https://docs.postgrest.org/en/v16/references/configuration.h...
I can't believe someone actually made this by design
Somehow it's okay to simultaneously set a golden path to less secure software to support your hockey stick growth model and then turn around and blame end users when it all goes wrong.
In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.
Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.
I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.
https://pocketbase.io/
True, but I've seen staff+ level developers get bit by this. What hope do vibe coders have?
Any tables created before the defaults put in place are of course still subject to the wide open defaults, because they would risk break existing users apps if they back-ported those.
People who don't get Postgres and RLS implement it sloppily and you inevitably get cases like this. You can put that on the user but I think platforms have a higher bar here to create experiences or interfaces where the easy path is the most secure one. There are obviously other parts of the process that can be leaky beyond beyond just the database config so the app architecture needs to make the system cohere together securely and I just don't feel like the existing platforms are fully up to the task.
The vibecoding tools like Lovable, bolt, v0, replit, base44 don't really attempt to be overtly transparent because that's not the point. They all sell the idea of a concierge service but that only works if the experience is actually "luxury" which in this case means you can trust in a guaranteed basic level of data privacy.
The analysis was conducted with the assistance of a lawyer specializing in data protection. A deliberate decision was made to share the dataset with Lovable so they could contact their customers and have the database access issues resolved.
No matter how annoying you find a particular response! Reply and say it’s garbage instead.
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.
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.
But unfortunately, it’s not always this transparent. In the US, doctors (particularly PE owned ones) often use AI in their backend in one form or the other. In one case, I observed their transcription service was using some LLM to help process data into medical record.
In other cases, your data may even be processed/leaked/trained without your explicit consent through a third party vendor that doesn’t interact directly with doctors office (physician office -> order sent to pharmacy -> pharmacy uses LLM to process data).
This is at least the case for the insidious CVS/Caremark conglomerate.
The people sharing their PII usually don't know that it's Lovable.
But they have tons of VC money so they'll get aquired by someone in the incestuous circle of SV investors.
Yes you will need SOME technical knowledge. But people are just lazy. Everyone can learn this stuff. Just ask any anthropic model how to deploy a website, it’ll tell you.
I'm the creator of Skape - an app building platform where the security is baked into the platform itself. Login and sharing data with other users all happens in the platform. This doesn't mean "your app shows its own UI and then feeds username/password to a login service" - I mean that Skape's UI handles login, and then while you use your app, Skape routes your data requests to your database. The app is treated as untrusted by the platform, which means app creators and users have to worry a lot less about the security of vibe coded apps.
I think that this is a better approach to security that will allow users to trust the software on the skape platform to a higher degree.
Check it out - https://skape.run/
Like mentioned elsewhere in this thread, there are doctors vibe coding shite and sending private medical data to Anthropic's servers, probably without even checking the "don't use for training lol" checkbox. Thousands of passports, invoices, whatever, are rn available on the open internet. People posting private company data on PUBLIC github repos (dealt with 2 such cases lol).
These individuals aren't held to the same standards, and right now nobody is enforcing the rules on them.
And maybe that's fine. Maybe we don't want to stifle innovation. But if my passport ends up on the dark web and I get identity theft'd, then I'd be pissed. There are REAL consequences.
Oh boy, open season on those entry points
although I don't use it enough to know the specific details of how it is infrastructured. But since the promise is that it writes any code that you want, it's logical that the arbitrary code is not a property of the code generating tool but of the user that generated the code!
Can someone please correct me if I'm wrong here, but isn't the article claiming that all data was publicly accessible with a read-only API key, also publicly shipped in each site?
Unless I'm missing something, no amount of digging into *published* data is a breach of anything. The act of publishing it is the leak, not the consumption.
Am I losing the plot?
I mostly see an accusation of downloading more data than needed to prove the point.
Lovable lets you do stuff without even understanding semantically what API or API Key means and how it can or should be used.
Moving too fast and putting the onus at the user is a bit shady.
Data being technically accessible doesn't mean it's meant to be accessed by anyone.
If I understand this right, this is the equivalent of leaving a house key hidden under the doormat. Just because it can be easily found doesn't mean anyone's just legally allowed to use it.
He seems a hard person to have sympathy for, which didn't help that much at all.
I went looking for any recent cases, here's one example[0] of a software provider being negligent, yet the security researcher got the axe:
> In the appeal proceedings on Monday, Aachen Regional Court adopted the assessment of Jülich District Court that access to the secured database constituted a criminal offense. Trial observers from the Chaos Computer Club reported that the court did not care how the defendant had obtained the password. The password was not easy to guess or publicly known, making access a criminal offense.
When I did some hacking myself ~15 years ago, I looked at these kinds of cases and learned to not touch any system that doesn't have a bounty program. Otherwise you put yourself at a lot of risk. Bug bounty programs prohibit access to sensitive data - so if you were to download data like it was done in the article, you might not only not be compensated, but also the company may decide to report you. No company wants to deal with leaked sensitive data, it's a huge business risk for them, so they may take more drastic measures in these cases.
[0]: https://www.heise.de/en/news/Modern-Solution-Court-of-Appeal...
https://csrc.nist.gov/glossary/term/inadvertent_disclosure