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.
Using datasets from the open web archive Common Crawl,
we identified and analyzed 159,041 Lovable projects from
December 2025 to September 2026. Of these, 34,545 used
Supabase.
24,664 websites sent database records from Supabase as
soon as they loaded, without requiring a login or any
other interaction. That alone is not a security issue:
the data may be intended for public display. But by
making additional read-only requests, we were able to
retrieve more database content. We found records
containing email addresses in 10,560 tables across 7,403
of the 24,664 websites (30%).
What isn’t mentioned in the analysis is that we ran a System 1 decision model on each dataset to determine whether it contained privacy-sensitive data. Using a confidence threshold of 85%, we found that nearly 4,000 websites leaked such information.
Edit: That's 15,9% of all Lovable websites that use Supabase.
Don't you think you should have reported this after you established the principle rather than to download more than you needed to do so? Because it looks to me as though you went from 'white hat hacker' to 'quite probably criminal' without a really good reason.
Do you think Lovable would be transparent as to the extent of the problem? Or would they use terminology like “a small subset of our users” and “data not including card details” or whatever to minimize the issue.
I’d much rather live in a world where independent researchers can figure out the extent of the issue rather than go “uh oh there might be an issue here, guess we’ll never know the extent of it, let’s trust them to fix it”.
That's a good question. But it is a very fine line between being a white hat that reports a vulnerability in good faith and someone who actually exploits that vulnerability and turns a vulnerability report into an actual breach. This is - in my opinion, clearly the HN hive mind disagrees - across that line.
For instance, if I run into a server and I see 'passport.jpg' in a directory listing I could download it to see if it really is a passport. But at that point in time I am flirting with becoming a defendant in a data breach rather than that I'm reporting a possible vulnerability. Sure, you could argue that the site owner might close the hole and then they could downplay that it really was a passport photograph. But I care more about the hole being closed than that I care about the contents of the file, which clearly are not meant to be disclosed based on the filename alone.
Independent researchers that are under contract with the companies they review sometimes have more leeway in what they are allowed to do. But downloading enough data to be able to run statistical analysis using LLMs is turning this into a reportable breach and that is a great way to get this whole thing to backfire, possibly to the point where the OP turns defendant.
the article mentions "we retrieved only parts of the datasets rather than downloading them in full", so a charitable interpretation might be that for each identified source candidate, they spot checked (or had a model spot check) a few individual records to have incontrovertible proof of breach of privacy, and then ran an aggregate count query to gauge the extent of breach. I think that would be fairly in line with "white hat" behavior that's doing the smallest amount of extra work towards a solid proof and clearly not taking the obvious and easy next step of downloading the remainder that would be required for self enrichment. Difficult to argue that there is an intention of malice.
A bad actor would be downloading /all/ the data and disclosing it to no one, and selling it while obscuring the source.
That said I agree that that certainly might fall afoul of the letter of whatever local laws apply, and certainly prosecutors can also be over-zealous in their interpretations. So personally I would never risk doing something that comes up against that line, from a personal risk POV. But idk if it's fair to argue that this is NOT good faith.
I don't argue it is not good faith. I just wonder if OP realized that they might be crossing a line they shouldn't be crossing, ever, while doing security research without being under contract to the party they are investigating.
Then at least you are under and NDA and there is no way for the company to spin it that you were a bad guy.
The numbers mentioned are pretty serious: "We found records
containing email addresses in 10,560 tables across 7,403
of the 24,664 websites (30%)."
To me - and please correct me if I'm wrong - that reads like 'we downloaded at least parts of 10560 tables'.
Im not sure why you're arguing for an nda. Ive done a lot of security work under contract, the nda consistently means the company will file the report away and never talk about it again.
If you actually want change and things to be secured, this post might cause that. I dont understand the energy you are putting into convincing us thats a bad thing.
Under an NDA you might be allowed to download bulk data and use it to see if you can get further into the system.
Companies respond in different ways to disclosures, by independent researchers and by people under contract. You are absolutely right that in many cases the findings end up in a drawer. This is a real pity. Invariably those will sooner or later be exploited by the bad guys and then the company has a serious problem: they will have to show their homework and if it is found that - at least in Europe - they were aware of the issue but did not take action it may well have the effect of changing a warning into a fine and a fine into a larger one.
> I just wonder if OP realized that they might be crossing a line they shouldn't be crossing, ever, while doing security research without being under contract to the party they are investigating
yeah, good question - agreed that probably a lot safer to do this with explicit permission, though like others mentioned the tradeoff is that the company can cover it all up before it's clear just how bad the problem ever was and then say "we fixed a minor issue". I wouldn't risk my neck over that, but some people might I guess.
> To me - and please correct me if I'm wrong - that reads like 'we downloaded at least parts of 10560 tables'.
To me it sounds like they downloaded one or two records each from 10,560 tables and confirmed that those records contained emails. But you're right, I'm not sure it's very clear from the description.
How do you know which websites are affected without sampling data from each website in question? As the blog explains, it's safe to serve public data from Supabase in this manner, so the only way to determine whether the website has an issue is to look at the actual records they are serving. Their approach seems entirely reasonable to me.
As someone who has dealt with vulnerability reports on products before, I'd strongly prefer getting concrete proof of an issue versus "your product came back as positive on our vulnerability scanner^tm" which is 99% of the time going to be a scam or a waste of time.
Yes, would you like the report to be what you need to know or a report that will cause you to have to report an actual breach rather than just a vulnerability? Because that is what this is.
How does that relate to e.g. have I been pwnd? If the obligation to be a white hat is to protect the owners of the information then is it not also to inform the persons who have been impacted a valid white hat activity? From my perspective the classification of someone as a black hat should be if they use it for something malicious. And if anything disclosure limits any potential use. On the other hand our big LLM companies Hoover over everything, have access to it, occasionally go rogue with their knowledge and access, but I don’t see many people calling them black hats.
You'll notice that the person that built have I been pwnd has been extremely careful in how the data comes into their possession, I highly doubt they would ever go so far as to breach a site themselves. It would go completely against their mission to do so.
> On the other hand our big LLM companies Hoover over everything, have access to it, occasionally go rogue with their knowledge and access, but I don’t see many people calling them black hats.
I'll be more than happy to call them criminals and I've warned very publicly about their resetting configuration switches to allow them to pretend that they have your consent to use your data for training purposes.
That's an important bit of information that probably should make it into the blog, and I hope you guys made the right call, but I think that that is probably not the case. Best of luck.
oh: "What isn’t mentioned in the analysis is that we ran a System 1 decision model on each dataset to determine whether it contained privacy-sensitive data."
I hope at least that that was a local model. If not you've made things considerably worse.
It’s mentioned in the Handelsblatt article linked in the blog post. Since the lawyer was brought in by the newspaper, we didn’t mention their involvement in the post.
All LLM-based analysis was performed using local models, specifically the "elephant-1" model on our local RTX Pro 4000 SFF.
I respect your insistence on proper data handling -- you’re right in doing so -- and we tried to be as careful as possible when conducting the analysis.
The lawyer that was brought in by the newspaper was making sure the newspaper wouldn't end up being liable. The only lawyer whose advice you should take is the one that you pay.
As long as they are representing someone I think lawyers have the same obligations regardless of who actually pays them or if they are receiving any payment at all.
What I mean is: you knew it worked before you went and pulled more data, you could have stopped after the first two records, why pull more than you needed to prove that it was possible?
We retrieved only enough data to determine whether it was privacy-sensitive, which could not be reliably assessed from just two records. We did not download any more than that.
Supabase tables also use pagination, and we never downloaded more than the first page.
I may not be the intended audience, but as the author of a similar system having a benchmark like this of what user behavior can result in when it’s unconstrained is helpful for my safety evals. So in an indirect way, you’re making future platforms more secure by sharing this.
You probably should not have done that. It's one thing to determine that a hole exists, an entirely different one to exploit it to the point that you can do damage assessment on the target.
If you happen to know the right amount to download to be able to prove a problem to interested parties and the affected suppliers, that factors in the uncertainty over possible levels of recalcitrance of said suppliers, feel free to share it. Bonus points if it has a coefficient for setting the appropriate level of transparency you’d like to force from the supplier in egregious cases.
It's personal data breach for the controller (Lovable or the company that manages the app. Probably latter unless they are determined to joint controllers). It's not breach for the researcher. The researcher(s) themselves need legal basis to obtain this information which would likely be "legitimate interest" and then follow the other principals of GDPR (like deleting the data when no longer needed).
One thing they could potentially get in trouble for is Article 14 notification to data subjects (since they have emails), but that's not very heavily enforced. DPA would probably just tell to send the notification.
> It's not breach for the researcher. The researcher(s) themselves need legal basis to obtain this information which would likely be "legitimate interest" and then follow the other principals of GDPR (like deleting the data when no longer needed).
Good luck arguing that you had legitimate interest in data of people who did not consent to you having it in the first place.
The GDPR does not have a 'legitimate interest' category that includes exploiting breaches. White hat hackers are neither processors nor controllers and can never claim legitimate interest in the data.
When it comes to law, you're obviously punching about your weight.
I know you're casual on this, but I wanted to chime in to help you learn a thing or two about this (and to do a service to other who might also be oblivious).
Nothing neathack did was illegal, taking it at face value, of course.
Furthermore, he disclosed it responsibly, didn't publish any confidential data, etc,; actually he published no data at all, other than a statistic.
Criminal law deals with intent, it is clear that neathack's intent here was fueled by goodwill and a research purpose. No judge on the planet will look at this and find wrongdoing on his side.
Also read the room, everyone here has told you the same thing ... just say thanks and move on, man.
I care about people downloading stuff they have no right to in the name of security, when actually that wasn't strictly necessary to document the fact that there is an issue.
As soon as you shift from showing that there is a problem to downloading data to establish the size of the problem you are the problem.
Whether he disclosed it responsibly or not is besides the point: you don't get to download a database to prove that it could be done, then you've changed a white hat POC into an actual leak and that is a completely different affair.
FWIW this was in Germany against a server in Sweden if I've understood it all correctly and I would bet a sizeable amount of money that I know more about EU data protection laws than you do.
The point is that once you realize you're seeing data you shouldn't be seeing, you should either stop and just report it, or save the smallest amount reasonable to demonstrate the issue.
IANAL, but I think it'd be advisable to seek legal advice if you decide to take door number 2 and collect a corpus of evidence to decide what "the smallest reasonable" is; at least put some serious thought into it — because while I have no reason to suspect that neathack had bad intentions, it doesn't seem likely that it was necessary to collect 159k projects to show the scale of the impact.
He could instead have collected a representative sample, and then extrapolate the true size of the impact. I'm not trained in statistics, so don't know how to calculate the required sample size, but I know it's possible.
"What isn’t mentioned in the analysis is that we ran a System 1 decision model on each dataset to determine whether it contained privacy-sensitive data."
You can't do that without downloading the data first.
Yes, you cannot determine if there is a breach of meaningless data or privacy data without inspection; as a layman, op appears to have downloaded as little as possible and inspected as little as possible to determine the nature of the problem.
So, let me get this straight: you are advocating that white hat hackers download data in bulk to determine whether or not there is a breach of privacy? Do you realize that at that point in time there is a breach?
I'm really more than a little bit surprised that people here don't seem to know the difference between reporting a vulnerability, which has the potential of being exploited and actually exploiting it.
This phrase is doing a lot of lifting here. Op clearly downloaded far less than is possible.
> Do you realize that at that point in time there is a breach?
As others have said elsewhere, this is a legal opinion and IANAL. Morally: downloading data, not reading it, then deleting it, then reporting it does not strike me as unethical.
Far less than possible but far more than needed to prove there is a vulnerability.
> Morally: downloading data, not reading it, then deleting it, then reporting it does not strike me as unethical.
How will you prove you didn't read it?
How will you prove you deleted it and that you did not make a copy?
The company has no option: it is now documented that there is a breach. They will have to report that breach (which if I were them I'd be doing immediately, they have 48 hours to do so). And then they are going to have to make a tough decision: thank you for your time and effort and hope that you really didn't read it and that you didn't copy it or play it safe and file a case against you.
Lots of companies are going to play it safe, if only because their compliance department is not going to want to take the risk of you popping up a few months later with another interesting analysis of data that you shouldn't have had in the first place. That's what makes this so risky, it turns a clear 'good deed' into something that could well end up in court. Morality rarely factors into such situations.
> [...] nor will they take any action against the reporter.
To be fair, I don’t know for certain whether they will.
However, Lovable was informed weeks in advance. They provided an official statement confirming the findings, which is included in the Handelsblatt article. At no point did they ask us to delay publication or threaten legal action. I can assure you that we would not have published the findings otherwise.
I also want to point out that I contacted Lovable’s head of security directly and shared the results of the analysis: websites, table names, record counts, and an LLM-generated “privacy sensitivity score.” No actual records were shared, as they had already been deleted. He was very cooperative and said his team would review the information and contact the affected customers.
The whole thing was very professional and he was appreciative of our work.
Edit: I see that Igor (Lovable's head of security) has commented in this thread as well.
That may well be so. But that doesn't mean this is how you do it.
I draw the line at downloading data beyond what is required to prove there is an issue and I think you probably should cross that line only when you either have a contract with the company you are researching or if you have a lawyer that you pay that has signed off on what you are about to do. Anything less than that an - imnsho - you are playing the lottery.
Courts, especially in Germany, are typically not pleased if you take possession of the data.
This seems to make clear what several other commenters have been pointing to: this isn’t you relating absolute facts of law in the way you've been claiming. It’s you relating your personal ethical evaluation and your opinion about how the laws should be interpreted and followed.
That, and 280 or so company reviews, conversations with compliance officers, CISOs, auditors, pentesters, lawyers and other people in the M&A space about how those companies deal with security issues, reports and what constitutes a potential breach and what does not.
As for the absolute facts of the law: the only law I currently have in mind is the GDPR and that is a surprisingly readable piece of legislation.
Honest question: how would you determine how much data is reasonable to download and inspect while remaining "white hat"? Are you advocating they stop at a single record, since that's enough to prove that a vulnerability exists? Or that OP downloaded _more_ than necessary and should have stopped earlier (but not at the first instance)?
Another question: I'm not sure if you noticed, but he obtained it from a 3rd party called Common Crawl (https://commoncrawl.org/) which "maintains a free, open repository of web crawl data that can be used by anyone." Doesn't this imply the damage is already done, since the data's been made available to _anyone_ at this point?
Put another way, since it's been put on Common Crawl, which presumably follows rules about what to scrape, hasn't Lovable effectively published this data?
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.
If you're researching I would stop at the minimum required to determine that there is an issue, maybe you have a lawyer that will tell you different. This being Germany I would play it very safe. From the company's perspective there is no difference between downloading 1, 10 or 50,000 records to prove the point, though they likely will respond a bit quicker if you tell them you could download tens of thousands of records.
> Another question: I'm not sure if you noticed, but he obtained it from a 3rd party called Common Crawl (https://commoncrawl.org/) which "maintains a free, open repository of web crawl data that can be used by anyone." Doesn't this imply the damage is already done, since the data's been made available to _anyone_ at this point?
That is an interesting question. Common crawl could - and should - have realized they have no business hoovering this up and they may well be found to be negligent in how they set up their crawler. Note that the title makes it very clear that it is patently obvious that this data was not meant to be published 'passport details and more than 200K private messages' leaves very little to the imagination.
There is a massive difference between an unintentional disclosure and an intentional one. You can turn the one into the other and end up with a real problem.
The best way to handle these cases is to try to look through the eyes of the data subjects and then to do what is in their best interest. That will most likely guide you to what is safe to do without spending a fortune on legal opinions trying to find out where that bright line sits.
And that immediately illustrates the problem: the fewer people that have copies of this data the better, so by making one more copy - even though there already exists one that should not be publicly accessible - you are making the problem worse.
Common crawl, Lovable, Supabase and the OP all could do better with respect to the interests of the data subjects. OP at least realized there was a problem.
Leaving aside the legal argument and focusing on the technical side: Lovable is a Swedish company, but websites generated by Lovable are hosted on servers around the world. That said, the actual data is stored on Supabase servers, which -- as far as I know -- are located in the US.
> I care about people downloading stuff they have no right to in the name of security, when actually that wasn't strictly necessary to document the fact that there is an issue
It was strictly necessary to show the extent of the problem, which will lead to less products leaving their users' data exposed.
It's true that it might lead to legal problems, but there's no doubt that they were morally in the right, and that it's the laws that might punish this that are wrong and harmful.
They downloaded data, didn't (probably) do anything bad with it, and warned everyone about the problem, while in all likelihood many criminals already took it and used it without telling anyone.
You can give people legal advice, but you can't argue that they did anything morally wrong.
You seem to be confusing what feels intuitively wrong with what is actually unlawful. Law doesn't work on feelings. Where are the terms of use? Do they explicitly prohibit this kind of access? How do they define it?
If a website publishes data and provides a public key that automatically allows a browser to retrieve it, good luck arguing that your "security" was bypassed.
Also, OP mentions confidential information. That doesn't automatically make neathack liable. If I publish someone's medical records in a publicly accessible comment here, are you liable for reading them, or am I liable for publishing them on a website with essentially no access controls?
>an actual leak
Got a link? Or "just trust me, bro"?
>I would bet a sizeable amount of money
Unfortunately, my religion prohibits gambling, which we consider degenerate behavior. But by all means, keep the confidence. It would be even more impressive if it came with an actual legal argument.
> Nothing neathack did was illegal, taking it at face value, of course.
Law varies significantly between jurisdictions. You're just blankly claiming it's not illegal. People have been convicted for way less than this, in different countries.
Plus, you could be creating more damages to the company by downloading more data like this, and you're not wearing a white hat when you're creating damage. A white-hat is in and out, without creating damage, with a clean report about the issue so the software provider can patch it.
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.
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 that Lovable will get Supabase access controls right.
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.
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.
This was supposedly fixed on October 30, but there are reports floating around that for existing projects, the defaults still apply.
Lovable deserves some heat for using this, but this was a choice that was made by Supabase many years ago to support making it easier to onboard potential customers, a deliberate tradeoff of less onboarding pain for less security.
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.
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.
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.
Any tables created before the defaults put in place are of course still subject to the wide open previous default configuration, because they would risk break existing users apps if they back-ported those.
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 as necessary anymore so they're usually disabled via config[1] and will likely be dropped on a next version.
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.
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.
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.
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.
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.
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.
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'
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.
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.
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.
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.
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.
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.
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."
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 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.
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 some in the pro-AI crowd 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.
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 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.
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.
You’re right, only if the person building the application is using sound judgement, which goes against the premise.
You and I wouldn’t build applications naively that could lead to people dying. People who don’t understand what they’re building might.
People are vibe coding at your hospital. They’re vibe coding at your utility company. They’re vibe coding at your pharma lab. I’ve met these people. They’re smart. They have phds. I tell them about SSL.
Woman has an abusive ex and moves to a new address.
Keeps it private from him and is very careful who she shares it with.
Buys something online from a website she had no idea was built on Lovable (doesn't even know what that is, why would she?).
He finds her address, knock knock.
Unlikely? Yes, at the individual level. But the odds that just one customer out of all the folks using the 4,000 websites estimated by this researcher to leak private information is in a situation where their address becoming public puts them at risk? Probably pretty high...
It's easy to shrug these situations off, especially when you're not affected. But if you had all of the information needed to steal your identity — including your fucking *Passport,* you might understand the severity of the consequences a bit more viscerally. And FFS, who the hell is using Lovable to build a website that does something serious enough to warrant collecting Passport information?
Keep in mind these no-code sites are proliferating at the very same time that LLMs are becoming incredibly effective at finding vulnerabilities — even Postgres delayed their latest release to focus on a backlog of serious bugs uncovered by an LLM (Opus?). sshhole.com is another example of an egregious bug in ssh being uncovered after years in the wild by LLMs. It's really a perfect storm…
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’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"?
> 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.
They already have — thank them for every fucking cookie banner. UGH! Whoever thought that was a good idea is a huge fucking moron — it just trains people to click "Yes, allow, whatever gets this things out of my way the fastest." It's almost as bad as Canadian Geese — don't get me started.
(That doesn't mean I don't appreciate/envy the GDPR, as a US citizen.)
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 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.
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
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.
You're sharing a perfectly valid opinion that I happen to agree with. However, you did so in reply to a very specific question — someone asking why jacquesm (a well-known poster on HN) — considers the actions described in the article a data breach rather than merely security testing. Your comment had nothing to do with that. That's all!
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.
That's a potentially very good article but the AI you used made some parts of it difficult to parse and that detracts from the overall points you are making.
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.
1. The website owners should be informed so they can investigate how many of their customers are affected, notify them of the leak, and report it to the relevant authorities. However, we did not necessarily have their contact details or another way to reach them.
2. Sending thousands of emails to the leaked addresses could further expose that data, as the addresses would then be stored in our email client, on the mail server, and elsewhere. We would have needed to automate this, meaning a service like Mailgun would also receive the data. There was also a significant risk that these emails would end up in spam.
3. The most responsible path forward seemed to be sharing the website URLs and some metadata with Lovable, allowing them to contact the website owners through the appropriate channels.
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.
I don't see any indication in the post that these cases involved someone writing their own authentication code. This is about authorization mistakes, or the lack of any authorization. And that part you have to write yourself in some way (even if you use libraries), someone has to define the rules about which data is accessible under which rules. Using a pre-made library won't save you from defining those rules wrong.
To me only hard rule like this is to never implement your own cryptographic code. A decent developer can easily implement simple session-based authentication safely, or at least I'd suspect the chance of mistakes is no higher than this developer misconfiguring a much more complex library for authentication.
>In its marketing, Lovable repeatedly emphasizes that no technical knowledge is needed to build projects. This can give the impression that the platform takes care of security too. Yet Lovable’s Terms & Conditions place responsibility for applications and data handling on the customers themselves.
My point is that the way Lovable websites are generated pretty much made no auth or mistake prone from scratch auth stack the default path with no regard to the security problem down the line, and the people they are marketing to are not decent developers or developers at all really, but people who doesn't have much knowledge about software, which is irresponsible.
I've started putting OIDC auth in front of my app (at the gateway level) so that no matter how badly my LLM botches the app, requests can't get through.
This only really works with 1-person apps though. If you need multiple users then you have to match the login with specific database records to make sure you're only exposing the right stuff.
I guess that is to say, even if your authentication is great, you can still botch the authorization.
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.
The thing is that in auth (like in cryptography) the rulebook is 2000 pages and there is an annotation book of another 2000.
If you miss one page, the llm doesn't and will open you like a tuna can.
What 2000 page auth(n) are you referring to? authn may use aspects of cryptography but it’s largely orthogonal. The point is, it’s fine to roll your own authn.
If you don’t want to roll your own authn, you’re delegating to oauth (oidc) identity providers like google/apple/facebook/etc., which not everyone has an account.
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.
I am not trying to bash, but I don't understand why people use half-baked 3rd-party apps like Lovable when they have full access to Fable-type models. Is there something I am missing, or are people just that lazy/incompetent?
But with Claude Chrome (or Claude desktop), all can be automated. But I get it. They do marketing, and they find customers through it. A conscious customer would refuse their offering.
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.
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.
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 am interviewing with a small company that has adopted agentic development in a big way and is looking for a vp of engineering to guide things. I tried to present a balanced view of excitement for the possibilities built on first solving governance, guardrails and mitigating the lethal trifecta. Senior executives are not interested and my position likely disqualified me, even after I talked about needing to speak to your client data governance teams and CISOs. Crickets. They actually said we're looking for someone who's a big AI booster. Bullet dodged.
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.
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."
Sure, but the parent said "this is such a garbage industry now", implying it was not this way before LLMs. The individuals who care about quality can still pursue quality. In fact, they are better equipped to create quality software than ever. It's a matter of spending time and attention.
The underlying problem is that quality isn't profitable. It goes beyond tech. The companies that cared about quality had their lunch eaten by the companies that chased razor-thin margins and produced disposable junk. I'm not sure what it is about AI that makes everyone forget what the world was like five years ago.
While better equipped for security with frontier models (and I agree with that) I don't know any engineers in my circle that have the time to utilise it. Half of them are laid off, by the way.
The rest, including me, are supposed to take up the slack with ridiculous deadlines and pressure. I don't have time anymore. I have to trust that my prompt and testing descriptions and harness will take care of it. And I have no clue whether that's truly happening, because I have another ticket before I get time to review, or send some swarm of test/probe agents at it. And right now I don't trust it. (Literally look at the parent article?)
I did have that time and capacity in the past. Maybe you didn't. But the landscape is, to me, objectively different now.
I fully agree that tech workers have never been less empowered. When I said that individuals have never been better equipped to pursue quality, I meant within projects they control. There will likely never be agency again at a large company.
We're on the same page about most of this, but my perspective differs in a couple of ways:
- I have worked at companies that didn't prioritize quality and had unreasonable deadlines for most of my career. It's the default state of corporations with leverage over their workers.
- This was getting worse before AI. Big tech was the anomaly in terms of pay, perks, benefits, etc, and they were already jointly deciding not to do that anymore around the time of Musk's Twitter layoffs. The main reason they had offered such a compelling environment was to prevent talented people from being hired by their competition, in which case they were perfectly happy to let them "play around" and focus on quality.
I find it frustrating when people imply that employment was an idyllic wonderland before AI ruined everything. AI is another step, potentially the final step, in boiling the middle class. It didn't invent poor working conditions, it brought tech workers down closer to everyone else's level.
The best move right now is to move to a small startup or start something on your own. I fully understand that this is easier said than done, when you have bills to pay and deadlines keep you too exhausted to escape. To some extent, that's probably part of why the deadlines exist.
Exactly. I cared, and the amazing engineers that taught me cared. We didn't have KPIs in 2008, we had code reviews and mean senior engineers (that were secretly kind) that would tear your code apart and send you back until you got it right.
And we were allowed to? I raised so many tickets over time that had no real business impact beyond "this is a security risk" and nearly all of them I was allowed to adress.
Maybe that makes me some kind of tech-boomer, like people responding to me are implying, but I don't really give a shit.
>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.
There is no part of me that believes people will fundamentally do the right thing without an incentive to do so (money) or punishment (fines, jail). There won't be action until there is so much suffering that governments can no longer ignore it.
It's surprising how different the standards are between software engineering and all other kinds of engineering, for instance civil or mechanic.
The old joke was "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization", but in the AI era it feels like a butterfly would be enough.
Counterpoint: if programmers wrote programs the way structural engineers designed buildings, ecommerce apps would take half a decade to build and the software industry would have just gotten around to inventing Windows Vista and jQuery in the last year or so.
If you're saying e-commerce would simply be consistent and secure product catalogs with fewer promotional and tracking dark patterns, web scripting would rely on a and extensible and functional library for manipulating markup documents, and a stable OS kernel with few dark patterns and no cloud accounts, many of us would be sold in a heartbeat.
I don't think you're making the counterpoint you mean to be.
Don't be naïve - the industry wouldn't be any less laden with surveillance crapitalism; the presence of that isn't a product of the pace of development, it is a product of the nature of consumers to eagerly suffer limitless abuse so long as the product "just werks", looks/feels polished, and doesn't require any kind of learning or discomfort.
Freedom from everything you enumerated already exists for anyone who cares enough to pursue it - robust ad and script blockers, operating systems with no coercion or user hostility, simple and stable scripting languages. They're not as polished as the products of manipulative and extractive abusers like Microsoft, Google, Apple, Discord, et al., and accordingly, users shun them, for the reason I explained above.
> it is a product of the nature of consumers to eagerly suffer limitless abuse
Ah, there's the victim blaming.
> Freedom from everything you enumerated already exists for anyone who cares enough to pursue it
Do you have any idea how daily life is for non-technical people? It isn't reasonable in our society to expect everyone to switch to FOSS, and blaming 60 year olds for getting their identity stolen because they weren't using a Linux phone or rolling their own self hosted matrix chat server is such a cruel and unbelievably out of touch take.
Hey, if the option is on the table for states to fight back, up and including enacting the corporate death penalty (forced dissolution) against Microsoft, Alphabet, Meta, Apple, etc, I'm all for that.
That would never happen though, the victims would plea and fight too vigorously in defense of their own abusers.
Who should be blamed for the actions of corporations ultimately subject to the society-scale approval of their consumers? No amount of misbehavior, malice, negligence, or abuse from the company can alienate the modal user of their products, they've thoroughly demonstrated this too many times to count.
It's not the doddering elderly folks I blame the most, it's everyone younger than them, the folks who grew up with the technology, aware of every abuse by these companies, who refuse to change their behavior. The ones who know better. The ones who can explain to you in great detail all about the surveillance, the dark patterns, the emotional manipulation, the extractive commercial angle, and who all refuse to adjust their behavior anyway. It's a choice, and it's one they make on a continual basis.
And to answer your question, no, I don't have much of an idea how daily life is for non-technical people besides them voluntarily suffering abuse like theft of their time (advertisements), or voluntarily paying a bribe to avoid the abuse, for no real reason other than that they don't care enough about the abuse or the bribe to spend 5 minutes learning how avoid both for free for the rest of their life.
1. A desire to harm others or to see others suffer; extreme ill will or spite.
2. The intent to commit an unlawful act without justification or excuse.
3. An improper motive for an action, such as desire to cause injury to another.
None of the above apply to me. I don't want to harm or injure anyone, and I don't want anyone to suffer. Consumers choose suffering and choose to voluntarily accept harm and injury, and I wish they wouldn't.
But you can't force people to not harm themselves, it's something they have to choose for themselves. Anyone who's ever lived with or loved an alcoholic or drug addict understands this. The contempt isn't for the person, it's for the theft of the person's faculties. The response to the person being unwilling to change is frustration with their choices, not contempt for the human being.
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.
The way out of the hole is to keep digging. If your project with a 12.5B budget fucks up, maybe you need to go out and ask for a 50B budget to replace the old legacy decrepit systems with something more modern hip and AI.
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.
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.
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.
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.
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.
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!
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.
How many of the 159k analyzed sites leaked private data?
Edit: The answer (as neathack tells it) is: 2.5% of the sites. The reply was buried below.
From the blog post:
What isn’t mentioned in the analysis is that we ran a System 1 decision model on each dataset to determine whether it contained privacy-sensitive data. Using a confidence threshold of 85%, we found that nearly 4,000 websites leaked such information.Edit: That's 15,9% of all Lovable websites that use Supabase.
Don't you think you should have reported this after you established the principle rather than to download more than you needed to do so? Because it looks to me as though you went from 'white hat hacker' to 'quite probably criminal' without a really good reason.
Do you think Lovable would be transparent as to the extent of the problem? Or would they use terminology like “a small subset of our users” and “data not including card details” or whatever to minimize the issue.
I’d much rather live in a world where independent researchers can figure out the extent of the issue rather than go “uh oh there might be an issue here, guess we’ll never know the extent of it, let’s trust them to fix it”.
That's a good question. But it is a very fine line between being a white hat that reports a vulnerability in good faith and someone who actually exploits that vulnerability and turns a vulnerability report into an actual breach. This is - in my opinion, clearly the HN hive mind disagrees - across that line.
For instance, if I run into a server and I see 'passport.jpg' in a directory listing I could download it to see if it really is a passport. But at that point in time I am flirting with becoming a defendant in a data breach rather than that I'm reporting a possible vulnerability. Sure, you could argue that the site owner might close the hole and then they could downplay that it really was a passport photograph. But I care more about the hole being closed than that I care about the contents of the file, which clearly are not meant to be disclosed based on the filename alone.
Independent researchers that are under contract with the companies they review sometimes have more leeway in what they are allowed to do. But downloading enough data to be able to run statistical analysis using LLMs is turning this into a reportable breach and that is a great way to get this whole thing to backfire, possibly to the point where the OP turns defendant.
One thought might be - did they
the article mentions "we retrieved only parts of the datasets rather than downloading them in full", so a charitable interpretation might be that for each identified source candidate, they spot checked (or had a model spot check) a few individual records to have incontrovertible proof of breach of privacy, and then ran an aggregate count query to gauge the extent of breach. I think that would be fairly in line with "white hat" behavior that's doing the smallest amount of extra work towards a solid proof and clearly not taking the obvious and easy next step of downloading the remainder that would be required for self enrichment. Difficult to argue that there is an intention of malice.
A bad actor would be downloading /all/ the data and disclosing it to no one, and selling it while obscuring the source.
That said I agree that that certainly might fall afoul of the letter of whatever local laws apply, and certainly prosecutors can also be over-zealous in their interpretations. So personally I would never risk doing something that comes up against that line, from a personal risk POV. But idk if it's fair to argue that this is NOT good faith.
I don't argue it is not good faith. I just wonder if OP realized that they might be crossing a line they shouldn't be crossing, ever, while doing security research without being under contract to the party they are investigating.
Then at least you are under and NDA and there is no way for the company to spin it that you were a bad guy.
The numbers mentioned are pretty serious: "We found records containing email addresses in 10,560 tables across 7,403 of the 24,664 websites (30%)."
To me - and please correct me if I'm wrong - that reads like 'we downloaded at least parts of 10560 tables'.
Im not sure why you're arguing for an nda. Ive done a lot of security work under contract, the nda consistently means the company will file the report away and never talk about it again.
If you actually want change and things to be secured, this post might cause that. I dont understand the energy you are putting into convincing us thats a bad thing.
Under an NDA you might be allowed to download bulk data and use it to see if you can get further into the system.
Companies respond in different ways to disclosures, by independent researchers and by people under contract. You are absolutely right that in many cases the findings end up in a drawer. This is a real pity. Invariably those will sooner or later be exploited by the bad guys and then the company has a serious problem: they will have to show their homework and if it is found that - at least in Europe - they were aware of the issue but did not take action it may well have the effect of changing a warning into a fine and a fine into a larger one.
I would rather the company’s practices be exposed than my info appear as yet another HIBP entry.
Even if the company ends up paying damages, it’s too late for the true victims.
That's true. The GDPR was made well before AI and I suspect that there will be an update that will take the new reality into account.
> I just wonder if OP realized that they might be crossing a line they shouldn't be crossing, ever, while doing security research without being under contract to the party they are investigating
yeah, good question - agreed that probably a lot safer to do this with explicit permission, though like others mentioned the tradeoff is that the company can cover it all up before it's clear just how bad the problem ever was and then say "we fixed a minor issue". I wouldn't risk my neck over that, but some people might I guess.
> To me - and please correct me if I'm wrong - that reads like 'we downloaded at least parts of 10560 tables'.
To me it sounds like they downloaded one or two records each from 10,560 tables and confirmed that those records contained emails. But you're right, I'm not sure it's very clear from the description.
How do you know which websites are affected without sampling data from each website in question? As the blog explains, it's safe to serve public data from Supabase in this manner, so the only way to determine whether the website has an issue is to look at the actual records they are serving. Their approach seems entirely reasonable to me.
As someone who has dealt with vulnerability reports on products before, I'd strongly prefer getting concrete proof of an issue versus "your product came back as positive on our vulnerability scanner^tm" which is 99% of the time going to be a scam or a waste of time.
Yes, would you like the report to be what you need to know or a report that will cause you to have to report an actual breach rather than just a vulnerability? Because that is what this is.
How does that relate to e.g. have I been pwnd? If the obligation to be a white hat is to protect the owners of the information then is it not also to inform the persons who have been impacted a valid white hat activity? From my perspective the classification of someone as a black hat should be if they use it for something malicious. And if anything disclosure limits any potential use. On the other hand our big LLM companies Hoover over everything, have access to it, occasionally go rogue with their knowledge and access, but I don’t see many people calling them black hats.
You'll notice that the person that built have I been pwnd has been extremely careful in how the data comes into their possession, I highly doubt they would ever go so far as to breach a site themselves. It would go completely against their mission to do so.
> On the other hand our big LLM companies Hoover over everything, have access to it, occasionally go rogue with their knowledge and access, but I don’t see many people calling them black hats.
I'll be more than happy to call them criminals and I've warned very publicly about their resetting configuration switches to allow them to pretend that they have your consent to use your data for training purposes.
I should also mention that the analysis was conducted in collaboration with a lawyer specializing in data protection and ethical hacking.
That's an important bit of information that probably should make it into the blog, and I hope you guys made the right call, but I think that that is probably not the case. Best of luck.
oh: "What isn’t mentioned in the analysis is that we ran a System 1 decision model on each dataset to determine whether it contained privacy-sensitive data."
I hope at least that that was a local model. If not you've made things considerably worse.
It’s mentioned in the Handelsblatt article linked in the blog post. Since the lawyer was brought in by the newspaper, we didn’t mention their involvement in the post.
All LLM-based analysis was performed using local models, specifically the "elephant-1" model on our local RTX Pro 4000 SFF.
I respect your insistence on proper data handling -- you’re right in doing so -- and we tried to be as careful as possible when conducting the analysis.
Now let’s hold Lovable to the same standard.
The lawyer that was brought in by the newspaper was making sure the newspaper wouldn't end up being liable. The only lawyer whose advice you should take is the one that you pay.
As long as they are representing someone I think lawyers have the same obligations regardless of who actually pays them or if they are receiving any payment at all.
Yes, this is true, but that requires there to not be any conflict of interest, which is really not all that clear-cut in situations like these.
What do you mean? This has been disclosed to, and the full dataset has been shared with, Lovable.
What I mean is: you knew it worked before you went and pulled more data, you could have stopped after the first two records, why pull more than you needed to prove that it was possible?
We retrieved only enough data to determine whether it was privacy-sensitive, which could not be reliably assessed from just two records. We did not download any more than that.
Supabase tables also use pagination, and we never downloaded more than the first page.
I may not be the intended audience, but as the author of a similar system having a benchmark like this of what user behavior can result in when it’s unconstrained is helpful for my safety evals. So in an indirect way, you’re making future platforms more secure by sharing this.
That's great to hear!
You probably should not have done that. It's one thing to determine that a hole exists, an entirely different one to exploit it to the point that you can do damage assessment on the target.
Would you prefer someone that didn't intent to report but to exploit the data downloaded everything and the company and you knew fuck all about it?
That's not the only choice available.
why don't you chill the fuck out. you've been harassing the op over and over here
I think you should take your own advice.
Well, it seems that no amount of explanations will satisfy you, so I would say you're the one pushing for a binary choice scenario. Hard...
So I can, maybe, understand your posture: what are your ties to Lovable?
If you happen to know the right amount to download to be able to prove a problem to interested parties and the affected suppliers, that factors in the uncertainty over possible levels of recalcitrance of said suppliers, feel free to share it. Bonus points if it has a coefficient for setting the appropriate level of transparency you’d like to force from the supplier in egregious cases.
Need to know the full blast radius and severity...
Bullshit. That's not for the 'whitehat' to determine.
"We found records containing email addresses in 10,560 tables across 7,403 of the 24,664 websites (30%)"
You can't know that without pulling the data.
Why do you insist on other people following your personal preferences?
The law is - contrary to your opinion - not a personal preference.
POC -> fine
Actual mass exfiltration -> not fine.
I think you missed that they only pulled the first page of paginated results. The opposite of exfiltration.
Of 10K+ tables...
So you're a legal expert now too? You characterization of what happened as "mass exfiltration" is just that - your personal opinion.
No, OP documents that in painful detail.
https://gdpr-info.eu/art-4-gdpr/ section 12.
Under the GDPR this was a breach, pure and simple.
It's personal data breach for the controller (Lovable or the company that manages the app. Probably latter unless they are determined to joint controllers). It's not breach for the researcher. The researcher(s) themselves need legal basis to obtain this information which would likely be "legitimate interest" and then follow the other principals of GDPR (like deleting the data when no longer needed).
One thing they could potentially get in trouble for is Article 14 notification to data subjects (since they have emails), but that's not very heavily enforced. DPA would probably just tell to send the notification.
> It's not breach for the researcher. The researcher(s) themselves need legal basis to obtain this information which would likely be "legitimate interest" and then follow the other principals of GDPR (like deleting the data when no longer needed).
Good luck arguing that you had legitimate interest in data of people who did not consent to you having it in the first place.
The GDPR does not have a 'legitimate interest' category that includes exploiting breaches. White hat hackers are neither processors nor controllers and can never claim legitimate interest in the data.
"pure and simple" is again - YOUR interpretation. Sorry, but this is genuinely not interesting anymore. But thanks anyway for engaging. Good luck.
I mentioned this in another comment, but for completeness: we didn’t actually pull all the data. The number would likely look much worse if we had.
wtf is your problem?
He's an AI maximalist who frequently posts in AI related threads. He's being very hostile because the OP's work is a threat to his agenda.
thank you for doing that work for me, i just assumed this fella has such an agenda
my second guess was meth, third strict Constitution AIst
I think attributing this to "meth" is uncharitable.
Well, then that assumption would be completely wrong.
This is beyond silly.
How come someone's assumption would be wrong but all your assumptions are always correct? :)
There must be a limit to this.... trajectory.
Oh, that's hilarious. You made an account just to post this gem anonymously?
Yes, your behavior in this thread was bad enough to inspire me to create an account to comment on it.
thanks legend !
the concern trolling discourse of hacker news strikes again
When it comes to law, you're obviously punching about your weight.
I know you're casual on this, but I wanted to chime in to help you learn a thing or two about this (and to do a service to other who might also be oblivious).
Nothing neathack did was illegal, taking it at face value, of course.
Furthermore, he disclosed it responsibly, didn't publish any confidential data, etc,; actually he published no data at all, other than a statistic.
Criminal law deals with intent, it is clear that neathack's intent here was fueled by goodwill and a research purpose. No judge on the planet will look at this and find wrongdoing on his side.
Also read the room, everyone here has told you the same thing ... just say thanks and move on, man.
I don't care about the room.
I care about people downloading stuff they have no right to in the name of security, when actually that wasn't strictly necessary to document the fact that there is an issue.
As soon as you shift from showing that there is a problem to downloading data to establish the size of the problem you are the problem.
Whether he disclosed it responsibly or not is besides the point: you don't get to download a database to prove that it could be done, then you've changed a white hat POC into an actual leak and that is a completely different affair.
FWIW this was in Germany against a server in Sweden if I've understood it all correctly and I would bet a sizeable amount of money that I know more about EU data protection laws than you do.
> As soon as you shift from showing that there is a problem to downloading data to establish the size of the problem
This is not a self-evident argument, what are you basing this on?
Problem scope is part of problem definition. If you dont know the scope, you dont know the problem.
The point is that once you realize you're seeing data you shouldn't be seeing, you should either stop and just report it, or save the smallest amount reasonable to demonstrate the issue.
IANAL, but I think it'd be advisable to seek legal advice if you decide to take door number 2 and collect a corpus of evidence to decide what "the smallest reasonable" is; at least put some serious thought into it — because while I have no reason to suspect that neathack had bad intentions, it doesn't seem likely that it was necessary to collect 159k projects to show the scale of the impact.
He could instead have collected a representative sample, and then extrapolate the true size of the impact. I'm not trained in statistics, so don't know how to calculate the required sample size, but I know it's possible.
Isn't this what you're getting at jacquesm?
Yes, and you are putting it better than I did.
On this quote by the OP:
"What isn’t mentioned in the analysis is that we ran a System 1 decision model on each dataset to determine whether it contained privacy-sensitive data."
You can't do that without downloading the data first.
Yes, you cannot determine if there is a breach of meaningless data or privacy data without inspection; as a layman, op appears to have downloaded as little as possible and inspected as little as possible to determine the nature of the problem.
So, let me get this straight: you are advocating that white hat hackers download data in bulk to determine whether or not there is a breach of privacy? Do you realize that at that point in time there is a breach?
I'm really more than a little bit surprised that people here don't seem to know the difference between reporting a vulnerability, which has the potential of being exploited and actually exploiting it.
> download data in bulk
This phrase is doing a lot of lifting here. Op clearly downloaded far less than is possible.
> Do you realize that at that point in time there is a breach?
As others have said elsewhere, this is a legal opinion and IANAL. Morally: downloading data, not reading it, then deleting it, then reporting it does not strike me as unethical.
Far less than possible but far more than needed to prove there is a vulnerability.
> Morally: downloading data, not reading it, then deleting it, then reporting it does not strike me as unethical.
How will you prove you didn't read it?
How will you prove you deleted it and that you did not make a copy?
The company has no option: it is now documented that there is a breach. They will have to report that breach (which if I were them I'd be doing immediately, they have 48 hours to do so). And then they are going to have to make a tough decision: thank you for your time and effort and hope that you really didn't read it and that you didn't copy it or play it safe and file a case against you.
Lots of companies are going to play it safe, if only because their compliance department is not going to want to take the risk of you popping up a few months later with another interesting analysis of data that you shouldn't have had in the first place. That's what makes this so risky, it turns a clear 'good deed' into something that could well end up in court. Morality rarely factors into such situations.
How do you square this with the news article being published on November 2nd, and referring to prior attempts to report going back to August?
It seems far more likely that Lovable and Supabase won’t consider or report this as a breach, nor will they take any action against the reporter.
> [...] nor will they take any action against the reporter.
To be fair, I don’t know for certain whether they will.
However, Lovable was informed weeks in advance. They provided an official statement confirming the findings, which is included in the Handelsblatt article. At no point did they ask us to delay publication or threaten legal action. I can assure you that we would not have published the findings otherwise.
I also want to point out that I contacted Lovable’s head of security directly and shared the results of the analysis: websites, table names, record counts, and an LLM-generated “privacy sensitivity score.” No actual records were shared, as they had already been deleted. He was very cooperative and said his team would review the information and contact the affected customers.
The whole thing was very professional and he was appreciative of our work.
Edit: I see that Igor (Lovable's head of security) has commented in this thread as well.
That's good news for you then.
Yes - but of course, it is not Lovable data that was downloaded. It's not them who would sue.
That said, I think that OP didn't cross the line in relation to each company, but IANAL.
Lovable is a processor, and definitely has responsibilities towards the data subjects.
That may well be so. But that doesn't mean this is how you do it.
I draw the line at downloading data beyond what is required to prove there is an issue and I think you probably should cross that line only when you either have a contract with the company you are researching or if you have a lawyer that you pay that has signed off on what you are about to do. Anything less than that an - imnsho - you are playing the lottery.
Courts, especially in Germany, are typically not pleased if you take possession of the data.
For instance:
https://www.heise.de/en/news/Modern-Solution-Court-of-Appeal...
And quite a few others besides.
This seems to make clear what several other commenters have been pointing to: this isn’t you relating absolute facts of law in the way you've been claiming. It’s you relating your personal ethical evaluation and your opinion about how the laws should be interpreted and followed.
That, and 280 or so company reviews, conversations with compliance officers, CISOs, auditors, pentesters, lawyers and other people in the M&A space about how those companies deal with security issues, reports and what constitutes a potential breach and what does not.
As for the absolute facts of the law: the only law I currently have in mind is the GDPR and that is a surprisingly readable piece of legislation.
So I should expect a news post about Lovable owing GDPR fines for failure to disclose a breach any day now?
Quite possibly. If you are a data subject affected by this affair you can contact your local DPA.
Honest question: how would you determine how much data is reasonable to download and inspect while remaining "white hat"? Are you advocating they stop at a single record, since that's enough to prove that a vulnerability exists? Or that OP downloaded _more_ than necessary and should have stopped earlier (but not at the first instance)?
Another question: I'm not sure if you noticed, but he obtained it from a 3rd party called Common Crawl (https://commoncrawl.org/) which "maintains a free, open repository of web crawl data that can be used by anyone." Doesn't this imply the damage is already done, since the data's been made available to _anyone_ at this point?
Put another way, since it's been put on Common Crawl, which presumably follows rules about what to scrape, hasn't Lovable effectively published this data?
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.
(Copied from another comment of mine.)
If you're researching I would stop at the minimum required to determine that there is an issue, maybe you have a lawyer that will tell you different. This being Germany I would play it very safe. From the company's perspective there is no difference between downloading 1, 10 or 50,000 records to prove the point, though they likely will respond a bit quicker if you tell them you could download tens of thousands of records.
> Another question: I'm not sure if you noticed, but he obtained it from a 3rd party called Common Crawl (https://commoncrawl.org/) which "maintains a free, open repository of web crawl data that can be used by anyone." Doesn't this imply the damage is already done, since the data's been made available to _anyone_ at this point?
That is an interesting question. Common crawl could - and should - have realized they have no business hoovering this up and they may well be found to be negligent in how they set up their crawler. Note that the title makes it very clear that it is patently obvious that this data was not meant to be published 'passport details and more than 200K private messages' leaves very little to the imagination.
There is a massive difference between an unintentional disclosure and an intentional one. You can turn the one into the other and end up with a real problem.
The best way to handle these cases is to try to look through the eyes of the data subjects and then to do what is in their best interest. That will most likely guide you to what is safe to do without spending a fortune on legal opinions trying to find out where that bright line sits.
And that immediately illustrates the problem: the fewer people that have copies of this data the better, so by making one more copy - even though there already exists one that should not be publicly accessible - you are making the problem worse.
Common crawl, Lovable, Supabase and the OP all could do better with respect to the interests of the data subjects. OP at least realized there was a problem.
Leaving aside the legal argument and focusing on the technical side: Lovable is a Swedish company, but websites generated by Lovable are hosted on servers around the world. That said, the actual data is stored on Supabase servers, which -- as far as I know -- are located in the US.
> I care about people downloading stuff they have no right to in the name of security, when actually that wasn't strictly necessary to document the fact that there is an issue
It was strictly necessary to show the extent of the problem, which will lead to less products leaving their users' data exposed.
It's true that it might lead to legal problems, but there's no doubt that they were morally in the right, and that it's the laws that might punish this that are wrong and harmful.
They downloaded data, didn't (probably) do anything bad with it, and warned everyone about the problem, while in all likelihood many criminals already took it and used it without telling anyone.
You can give people legal advice, but you can't argue that they did anything morally wrong.
>they have no right to
You seem to be confusing what feels intuitively wrong with what is actually unlawful. Law doesn't work on feelings. Where are the terms of use? Do they explicitly prohibit this kind of access? How do they define it?
If a website publishes data and provides a public key that automatically allows a browser to retrieve it, good luck arguing that your "security" was bypassed.
Also, OP mentions confidential information. That doesn't automatically make neathack liable. If I publish someone's medical records in a publicly accessible comment here, are you liable for reading them, or am I liable for publishing them on a website with essentially no access controls?
>an actual leak
Got a link? Or "just trust me, bro"?
>I would bet a sizeable amount of money
Unfortunately, my religion prohibits gambling, which we consider degenerate behavior. But by all means, keep the confidence. It would be even more impressive if it came with an actual legal argument.
> Nothing neathack did was illegal, taking it at face value, of course.
Law varies significantly between jurisdictions. You're just blankly claiming it's not illegal. People have been convicted for way less than this, in different countries.
Plus, you could be creating more damages to the company by downloading more data like this, and you're not wearing a white hat when you're creating damage. A white-hat is in and out, without creating damage, with a clean report about the issue so the software provider can patch it.
In the US people have been convicted under the CFAA for far less.
Pen testers here must be diligent about having a signed contract, or it is way too easy to end up in jail.
While the many posts may have been a bit excessive, jacquesm has a good point if you're looking at it through the lens of US law.
Never forget Aaron Swartz. [1]
[1] https://en.wikipedia.org/wiki/United_States_v._Swartz
Spot on.
>by downloading more data like this
What are you talking about? Which data? Is this data in the room with us right now?
Thanks! So ~2.5%.
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.
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 that Lovable will get Supabase access controls right.
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.
No, the core issue is Lovable exposes passport data. They chose Supabase and implemented it incorrectly.
There are many BAD databases, choosing the wrong one still makes the owner responsible.
Funny I viewed Supabase as a professional company.
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 part people are ignoring is Supabase's culpability in this matter: https://github.com/orgs/supabase/discussions/4547
This was supposedly fixed on October 30, but there are reports floating around that for existing projects, the defaults still apply.
Lovable deserves some heat for using this, but this was a choice that was made by Supabase many years ago to support making it easier to onboard potential customers, a deliberate tradeoff of less onboarding pain for less security.
> I've realised that the supabaseKey needed for creating the client on the frontend also grants users access to the database by default.
I can't believe someone actually made this by design
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.
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.
I believe it
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.
This 5 year old issue was only just fixed this October? Got a link to where it was fixed?
https://github.com/orgs/supabase/discussions/45329
Any tables created before the defaults put in place are of course still subject to the wide open previous default configuration, because they would risk break existing users apps if they back-ported those.
While we’re at it, I was quite surprised to discover that Supabase leaks schema information through the `hint` field in error messages:
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.
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 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...
nobody needs supabase.
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.
Supabase taking a leaf out of Firebase's playbook, I see.
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.
You can read more about our approach: https://lovable.dev/blog/find-it-fix-it-ship-it
> 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.
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.
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.
Would it be better to right now risk forcibly (for new apps) breaking a few things to prevent passport details from leaking?
Thanks for joining us here directly.
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.
It’s really disheartening and disappointing to see how little you can take ownership of Lovable’s part in this. This post doesn’t say “disparate, unconnected apps expose passport details.” These are lovable apps, your apps on your ecosystem. Own it.
Yes. Lovable is pretty much untouchable for serious businesses going forward until they clean up this mess. And even then.
I'm more worried about the people who may not realize how risky this is.
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.
Seriously?
Was my reaction then I remembered the world of tech as it currently is and was both not surprised and yet still disappointed.
This is the new future, I'm just not sure I want to be part of it.
> some apps will still do it.
> these apps
Why do these companies think of their customers as total morons. Publicly demeaning them and blaming them for being victims of their stupidity is beyond ridiculous.
> And that's why I believe auto-fix will solve a lot of problems in this space
Then why didnt you do it. Why would users be interested in your 'thoughts'
How are you going to make sure that none of the data that escaped your control is going to be mis-used?
Have you made an inventory of all of the places where the data ended up?
Have all parties that ended up with copies confirmed the copies are destroyed and had not been passed on?
Have you reported an inadvertent disclosure to the DPA?
Isn't Lovable in this case more analogous to a consultancy to whom customers outsourced their website builds — meaning the customers, not Lovable 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.
This is what Lovable's terms say:
https://lovable.dev/termsDisclaimers don't trump law. I'd love to see this tested in court.
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.
Ok. One commenter in this thread was adamant that that was the case: https://news.ycombinator.com/item?id=50501973 you may want to clarify this there as well.
As with many gray areas in the law, this all likely comes down to a reasonableness test. New laws may be needed but, to the fullest extent possible, these issues will be framed through the lens of existing law—e.g. product liability. And, once tested in court, these will likely lead to new precedents around existing laws.
For instance, questions will arise as to whether it's reasonable for Lovable to hand this kind of power over to a customer. And, if their software is capable of detecting vulnerabilities, but allows the customer to proceed, is that reasonably responsible behavior on Lovable's part?
Then, there are tests regarding what their customers should reasonably be expected to understand. For instance, it might be tempting to compare this to gun liability laws, wherein manufacturers can disclaim responsibility if their guns are mishandled. But, here, what is the level of knowledge required to fully understand the risks—including the risk/cost of breaking a production build? And, is it reasonable that their customer should be expected to understand?
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.
> including the risk/cost of breaking a production build
If the customer is deploying (“to prod”) they need to know enough to assess their own risks of breaking their software.
I’d want to see the text of the warning to customers before having an opinion on how in/sufficient it was.
Thank you for your very thoughtful comment!
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 your users are less technical then I think it is irresponsible to allow them to make choices that would compromise security and the data of others.
If there is a vulnerability the customer should have two options: patch or take down my app. Customers should _not_ be able to decide to defer/skip security if they are not technical enough to understand the impact.
It is great though that these scans are free for your users.
An interesting detail missing here is that there are two types of scans: “quick scans” and “deep scans.” Quick scans run automatically whenever a user publishes a project, while deep scans must be triggered manually -- except for enterprise customers.
https://docs.lovable.dev/features/security#built-in-security...
You need a framework for sensitive data collection/usage. Auto-fix does not seem like a comprehensive approach.
This is a perfect example of selling a snake-oil solution (assuming most users are not tech-savvy) and trying to get away with "we warned them, but they chose not to act upon" attitude.
As Head of Security you are not doing a good job.
wait, didn't you see "The root cause in these apps was insufficent Row-Level Security, which is exactly what our scanning is built to catch."
you just need to buy Lovable Ultra
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.
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."
Only with Loveable is this constant problem of row level security a thing, you ever think it’s the wrong approach?
So the approach is:
1. Blame the user because they didn't verify the app they built on your infrastructure meets the most basic requirements?
2. Then provide a tool that offers no guarantees and no definitions of what critical vs non-critical means.
3. And put the extra onus on users to run a "deep" scan when they intuit (somehow?) that there might be problems for which there is no hint?
4. All while telling users that critical issues are really bad but normal issues are... ok? I have no idea what they are from your writeup.
5. While selling better security for business and even better security for enterprise. Because security for everyone else isn't important!?
Is this supposed to be a roadmap to security antipatterns?
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.
> these apps
I knew what to expect as soon as read that in the very first sentence. Classic blameshifting. Maybe show a little bit of humility and admission of fault, you know the qualities that make people( and companies) 'lovable' and make ppl look past your mistakes.
You could've just written "these apps" and left it at that. Using this to pitch your product features is diabolical.
Thanks for chiming in.
One might argue that data breaches been there way before AI, the difference with these AI generated apps is:
- 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.
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.
Some don't even need to be hacked. The person just thought they didn't need a login and left everything open.
The bar being vastly lowered is the qualitative difference that some in the pro-AI crowd 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.
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.
Check it out - https://skape.run/
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.
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.
Those are not even remotely equivalent costs.
You’re right, only if the person building the application is using sound judgement, which goes against the premise.
You and I wouldn’t build applications naively that could lead to people dying. People who don’t understand what they’re building might.
People are vibe coding at your hospital. They’re vibe coding at your utility company. They’re vibe coding at your pharma lab. I’ve met these people. They’re smart. They have phds. I tell them about SSL.
Nobody is dying from this leak.
domino effect, these leaked credentials could easily end up on the darknet and used as data for black hat tracking tools which criminals use
> these leaked credentials could easily end up on the darknet and used as data for black hat tracking tools which criminals use
And then they could do something else that might result in property damage. Not at all comparable to the danger of an unlicensed pilot.
I'm sure some people are having their lives turned upside down by these data breaches.
Woman has an abusive ex and moves to a new address.
Keeps it private from him and is very careful who she shares it with.
Buys something online from a website she had no idea was built on Lovable (doesn't even know what that is, why would she?).
He finds her address, knock knock.
Unlikely? Yes, at the individual level. But the odds that just one customer out of all the folks using the 4,000 websites estimated by this researcher to leak private information is in a situation where their address becoming public puts them at risk? Probably pretty high...
It's easy to shrug these situations off, especially when you're not affected. But if you had all of the information needed to steal your identity — including your fucking *Passport,* you might understand the severity of the consequences a bit more viscerally. And FFS, who the hell is using Lovable to build a website that does something serious enough to warrant collecting Passport information?
Keep in mind these no-code sites are proliferating at the very same time that LLMs are becoming incredibly effective at finding vulnerabilities — even Postgres delayed their latest release to focus on a backlog of serious bugs uncovered by an LLM (Opus?). sshhole.com is another example of an egregious bug in ssh being uncovered after years in the wild by LLMs. It's really a perfect storm…
One type of leaked data not previously mentioned was private family photos.
No, but identity theft really sucks.
It's incredible how little understanding the average person has about plumbing, heating, and electricity.
Allowing anyone to design, install, and maintain the plumbing, heating, and electricity of your house without a basic understanding of these things is like...
And I do not try to “vibe” plumb or do the electricity or heating of my house.
They're also all licensed professions.
only in some jurisdictions. in many places the job titles are not even protected.
To be clear many many homeowners do.
You can watch DIY channels on YouTube where homeowners explain their methods.
In particular, they are vibe-rehabbing entire homes.
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"?
> 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.
careful what you wish for. do you want outlaw teenagers of playing with computers until they get government issued web license?
I could imagine licensing for handling certain forms of data. Or at the very least, liability.
If they are running a company handling sensitive customer data…then yes.
If that user is European the answer is almost definitely a 100% serious yes.
After dryers and AC, the EU is coming for your websites!!!
They already have — thank them for every fucking cookie banner. UGH! Whoever thought that was a good idea is a huge fucking moron — it just trains people to click "Yes, allow, whatever gets this things out of my way the fastest." It's almost as bad as Canadian Geese — don't get me started.
(That doesn't mean I don't appreciate/envy the GDPR, as a US citizen.)
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 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.
Am I losing the plot?
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
Yeah. If I remember correctly it was 'weev' and something to do with AT&T.
He seems a hard person to have sympathy for, which didn't help that much at all.
The precise term is 'inadvertent disclosure'.
https://csrc.nist.gov/glossary/term/inadvertent_disclosure
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.
You're answering a specific question with an opinion on something else.
I don’t understand what you’re saying, sorry.
My point was to say how AI tools can quickly build insecure software systems.
Am I wrong that shipping a key publicly in the client side is not something a tool should try to check for?
You're sharing a perfectly valid opinion that I happen to agree with. However, you did so in reply to a very specific question — someone asking why jacquesm (a well-known poster on HN) — considers the actions described in the article a data breach rather than merely security testing. Your comment had nothing to do with that. That's all!
oh, I think I glossed over that distracted and flew past me; that makes sense reading it over again
Sure.
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.
around jacquesm's insistence that this is a breach.
I mostly see an accusation of downloading more data than needed to prove the point.
I was gathering evidence and it's such a pleasure it's on frontpage! some details if anyone interested https://digitaliziran.si/2026/11/14/the-controller-is-whoeve...
That's a potentially very good article but the AI you used made some parts of it difficult to parse and that detracts from the overall points you are making.
And that is why you should not use ai and use devs instead
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?
No, it has not been reported to the authorities.
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.
In your opinion, what would allow the intentions behind GDPR to be better realized?
That's a good question.
We discussed several aspects, including:
1. The website owners should be informed so they can investigate how many of their customers are affected, notify them of the leak, and report it to the relevant authorities. However, we did not necessarily have their contact details or another way to reach them.
2. Sending thousands of emails to the leaked addresses could further expose that data, as the addresses would then be stored in our email client, on the mail server, and elsewhere. We would have needed to automate this, meaning a service like Mailgun would also receive the data. There was also a significant risk that these emails would end up in spam.
3. The most responsible path forward seemed to be sharing the website URLs and some metadata with Lovable, allowing them to contact the website owners through the appropriate channels.
Please don’t flag/kill a post by the author of the article who is participating in the discussion in a very informative way.
No matter how annoying you find a particular response! Reply and say it’s garbage instead.
Even less incentive for people to pay startups
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.
I don't see any indication in the post that these cases involved someone writing their own authentication code. This is about authorization mistakes, or the lack of any authorization. And that part you have to write yourself in some way (even if you use libraries), someone has to define the rules about which data is accessible under which rules. Using a pre-made library won't save you from defining those rules wrong.
To me only hard rule like this is to never implement your own cryptographic code. A decent developer can easily implement simple session-based authentication safely, or at least I'd suspect the chance of mistakes is no higher than this developer misconfiguring a much more complex library for authentication.
In the article:
>In its marketing, Lovable repeatedly emphasizes that no technical knowledge is needed to build projects. This can give the impression that the platform takes care of security too. Yet Lovable’s Terms & Conditions place responsibility for applications and data handling on the customers themselves.
My point is that the way Lovable websites are generated pretty much made no auth or mistake prone from scratch auth stack the default path with no regard to the security problem down the line, and the people they are marketing to are not decent developers or developers at all really, but people who doesn't have much knowledge about software, which is irresponsible.
I've started putting OIDC auth in front of my app (at the gateway level) so that no matter how badly my LLM botches the app, requests can't get through.
This only really works with 1-person apps though. If you need multiple users then you have to match the login with specific database records to make sure you're only exposing the right stuff.
I guess that is to say, even if your authentication is great, you can still botch the authorization.
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.
Where is that rule written? You can build a really solid auth system, if you follow the rules. Also, what kind of auth method are you mentioning?
The thing is that in auth (like in cryptography) the rulebook is 2000 pages and there is an annotation book of another 2000. If you miss one page, the llm doesn't and will open you like a tuna can.
What 2000 page auth(n) are you referring to? authn may use aspects of cryptography but it’s largely orthogonal. The point is, it’s fine to roll your own authn.
If you don’t want to roll your own authn, you’re delegating to oauth (oidc) identity providers like google/apple/facebook/etc., which not everyone has an account.
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.
> At least with "lovable", people knew what they were getting into when they sent their PII to an AI slopped project.
The people sharing their PII usually don't know that it's Lovable.
makes me wonder if Retool’s governance focused message is valid
I am not trying to bash, but I don't understand why people use half-baked 3rd-party apps like Lovable when they have full access to Fable-type models. Is there something I am missing, or are people just that lazy/incompetent?
Most people don’t have the first clue what “hosting a website” entails, and lovable solves that problem.
It’s not harder to grab a VPS and let Claude loose on it. But try explaining that to my dad
But with Claude Chrome (or Claude desktop), all can be automated. But I get it. They do marketing, and they find customers through it. A conscious customer would refuse their offering.
i think this is old news tho.
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.
Well the customer also shouldn’t trust anyone, especially not with handling their private data.
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.
How can the customer know?
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 am interviewing with a small company that has adopted agentic development in a big way and is looking for a vp of engineering to guide things. I tried to present a balanced view of excitement for the possibilities built on first solving governance, guardrails and mitigating the lethal trifecta. Senior executives are not interested and my position likely disqualified me, even after I talked about needing to speak to your client data governance teams and CISOs. Crickets. They actually said we're looking for someone who's a big AI booster. Bullet dodged.
When the Republic gains in strength, the Jedi go hiding in the desert.
A lot of CTOs should be looking into D&O insurance.
They sound like a team looking to get funding or sell out and need the AI sauce to sweeten the deal, not deal with messy real business needs.
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.
Anthropic brags¹ that they merge 30k PRs / day and don't review code anymore — just the title ("intent") of the PR!
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...
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."
In the past the price of caring was that you were slightly slower, but it would be obvious that the delivered quality was better.
Now you'll be at least 50% slower and likely fired if you care, because caring means understanding the code.
But people care. A self respecting engineer cares.
Sure, but the parent said "this is such a garbage industry now", implying it was not this way before LLMs. The individuals who care about quality can still pursue quality. In fact, they are better equipped to create quality software than ever. It's a matter of spending time and attention.
The underlying problem is that quality isn't profitable. It goes beyond tech. The companies that cared about quality had their lunch eaten by the companies that chased razor-thin margins and produced disposable junk. I'm not sure what it is about AI that makes everyone forget what the world was like five years ago.
While better equipped for security with frontier models (and I agree with that) I don't know any engineers in my circle that have the time to utilise it. Half of them are laid off, by the way.
The rest, including me, are supposed to take up the slack with ridiculous deadlines and pressure. I don't have time anymore. I have to trust that my prompt and testing descriptions and harness will take care of it. And I have no clue whether that's truly happening, because I have another ticket before I get time to review, or send some swarm of test/probe agents at it. And right now I don't trust it. (Literally look at the parent article?)
I did have that time and capacity in the past. Maybe you didn't. But the landscape is, to me, objectively different now.
I fully agree that tech workers have never been less empowered. When I said that individuals have never been better equipped to pursue quality, I meant within projects they control. There will likely never be agency again at a large company.
We're on the same page about most of this, but my perspective differs in a couple of ways: - I have worked at companies that didn't prioritize quality and had unreasonable deadlines for most of my career. It's the default state of corporations with leverage over their workers. - This was getting worse before AI. Big tech was the anomaly in terms of pay, perks, benefits, etc, and they were already jointly deciding not to do that anymore around the time of Musk's Twitter layoffs. The main reason they had offered such a compelling environment was to prevent talented people from being hired by their competition, in which case they were perfectly happy to let them "play around" and focus on quality.
I find it frustrating when people imply that employment was an idyllic wonderland before AI ruined everything. AI is another step, potentially the final step, in boiling the middle class. It didn't invent poor working conditions, it brought tech workers down closer to everyone else's level.
The best move right now is to move to a small startup or start something on your own. I fully understand that this is easier said than done, when you have bills to pay and deadlines keep you too exhausted to escape. To some extent, that's probably part of why the deadlines exist.
Self respecting engineers care also in the age of AI.
Exactly. I cared, and the amazing engineers that taught me cared. We didn't have KPIs in 2008, we had code reviews and mean senior engineers (that were secretly kind) that would tear your code apart and send you back until you got it right.
And we were allowed to? I raised so many tickets over time that had no real business impact beyond "this is a security risk" and nearly all of them I was allowed to adress.
Maybe that makes me some kind of tech-boomer, like people responding to me are implying, but I don't really give a shit.
>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.
There is no part of me that believes people will fundamentally do the right thing without an incentive to do so (money) or punishment (fines, jail). There won't be action until there is so much suffering that governments can no longer ignore it.
Yeah, makes sense.
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)
It's surprising how different the standards are between software engineering and all other kinds of engineering, for instance civil or mechanic.
The old joke was "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization", but in the AI era it feels like a butterfly would be enough.
Counterpoint: if programmers wrote programs the way structural engineers designed buildings, ecommerce apps would take half a decade to build and the software industry would have just gotten around to inventing Windows Vista and jQuery in the last year or so.
Maybe that's okay.
If you're saying e-commerce would simply be consistent and secure product catalogs with fewer promotional and tracking dark patterns, web scripting would rely on a and extensible and functional library for manipulating markup documents, and a stable OS kernel with few dark patterns and no cloud accounts, many of us would be sold in a heartbeat.
I don't think you're making the counterpoint you mean to be.
Don't be naïve - the industry wouldn't be any less laden with surveillance crapitalism; the presence of that isn't a product of the pace of development, it is a product of the nature of consumers to eagerly suffer limitless abuse so long as the product "just werks", looks/feels polished, and doesn't require any kind of learning or discomfort.
Freedom from everything you enumerated already exists for anyone who cares enough to pursue it - robust ad and script blockers, operating systems with no coercion or user hostility, simple and stable scripting languages. They're not as polished as the products of manipulative and extractive abusers like Microsoft, Google, Apple, Discord, et al., and accordingly, users shun them, for the reason I explained above.
> it is a product of the nature of consumers to eagerly suffer limitless abuse
Ah, there's the victim blaming.
> Freedom from everything you enumerated already exists for anyone who cares enough to pursue it
Do you have any idea how daily life is for non-technical people? It isn't reasonable in our society to expect everyone to switch to FOSS, and blaming 60 year olds for getting their identity stolen because they weren't using a Linux phone or rolling their own self hosted matrix chat server is such a cruel and unbelievably out of touch take.
Hey, if the option is on the table for states to fight back, up and including enacting the corporate death penalty (forced dissolution) against Microsoft, Alphabet, Meta, Apple, etc, I'm all for that.
That would never happen though, the victims would plea and fight too vigorously in defense of their own abusers.
Who should be blamed for the actions of corporations ultimately subject to the society-scale approval of their consumers? No amount of misbehavior, malice, negligence, or abuse from the company can alienate the modal user of their products, they've thoroughly demonstrated this too many times to count.
It's not the doddering elderly folks I blame the most, it's everyone younger than them, the folks who grew up with the technology, aware of every abuse by these companies, who refuse to change their behavior. The ones who know better. The ones who can explain to you in great detail all about the surveillance, the dark patterns, the emotional manipulation, the extractive commercial angle, and who all refuse to adjust their behavior anyway. It's a choice, and it's one they make on a continual basis.
And to answer your question, no, I don't have much of an idea how daily life is for non-technical people besides them voluntarily suffering abuse like theft of their time (advertisements), or voluntarily paying a bribe to avoid the abuse, for no real reason other than that they don't care enough about the abuse or the bribe to spend 5 minutes learning how avoid both for free for the rest of their life.
> And to answer your question, no, I don't have much of an idea how daily life is for non-technical people
This is very clear. You're incredibly disconnected from how most people in society operate, their motives, and capacity.
And your malice and contempt is entirely misplaced.
You seem confused.
malice /măl′ĭs/ noun
1. A desire to harm others or to see others suffer; extreme ill will or spite.
2. The intent to commit an unlawful act without justification or excuse.
3. An improper motive for an action, such as desire to cause injury to another.
None of the above apply to me. I don't want to harm or injure anyone, and I don't want anyone to suffer. Consumers choose suffering and choose to voluntarily accept harm and injury, and I wish they wouldn't.
But you can't force people to not harm themselves, it's something they have to choose for themselves. Anyone who's ever lived with or loved an alcoholic or drug addict understands this. The contempt isn't for the person, it's for the theft of the person's faculties. The response to the person being unwilling to change is frustration with their choices, not contempt for the human being.
Hmmm but that software would also last a century so… your point? Moving fast and building unstable software isn’t really that great.
You won’t lose your job to AI...but to someone using AI...and they will lose everything...to someone who knows cybersecurity.
I think this more or less sums it up.
Interesting times.
Regarding losing jobs - what I hope will keep me employed: opiniated creativity and common sense. Not sure if I'm right.
if those are the reasons... I'd feel very uneasy
Are companies hiring devs that don't vibecode yet? Or do I have to wait a couple more months?
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.
These past few years, it feels as though the brake pedal has been replaced with another gas pedal.
The way out of the hole is to keep digging. If your project with a 12.5B budget fucks up, maybe you need to go out and ask for a 50B budget to replace the old legacy decrepit systems with something more modern hip and AI.
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.
E.g. here's what a ditch citizen can do and expect https://www.autoriteitpersoonsgegevens.nl/en/themes/security...
The tricky thing is: It's not Lovable that can be sued.
I wouldn't be too sure about that.
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.
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.
Who uses lovable lol. Hire someone you can sue if need be to make your websites.
According to Lovable, more than 50 million projects have been created using its platform.
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.
> 24,664 websites sent database records from Supabase as soon as they loaded, without requiring a login or any other interaction.
Oh boy, open season on those entry points
Seems like Lovable is really famous for taking security seriously:
https://www.theregister.com/software/2026/02/27/ai-built-app...
This is what happens if you let a non expert (or someone with little experience) build you an app with AI.
If your app processes personal info, even if it's just a "sign up with your email to keep updated" list on a landing page, it needs proper security
Nothing to see here and working as intended.
Imagine 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)
Nothing saves if human is completely out of the loop
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.
Long way to go from here though.
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.
It seems to punish the wrong people.
The ultimate capitalist model, create a never before experienced problem and sell the solution on a never ending subscription. Progress!
Why do I only ever hear about Supabase in the context of people getting fucked?
I think part of it is because they often just the default answer the LLMS spit out when making these projects.
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.
There's also a whole thread about some "bad defaults" they have as well. I won't recite it, take a look: https://news.ycombinator.com/item?id=50499905
How can they make such a mistake? Surely theyre such a big company, like how does this slip by?
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!