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.

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

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.

Those are not even remotely equivalent costs.

It's incredible how little understanding the average person has about plumbing, heating, and electricity.

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

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.

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.

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.

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?

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

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

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.

Well the customer also shouldn’t trust anyone, especially not with handling their private data.

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.

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

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.

You won’t lose your job to AI...but to someone using AI...and they will lose everything...to someone who knows cybersecurity.

These past few years, it feels as though the brake pedal has been replaced with another gas pedal.

[flagged]

[flagged]

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.