Hacker News

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

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?

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.

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.

> 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

This 5 year old issue was only just fixed this October? Got a link to where it was fixed?

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

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.

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.

Those are not even remotely equivalent costs.

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

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?

The precise term is 'inadvertent disclosure'.

https://csrc.nist.gov/glossary/term/inadvertent_disclosure

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.

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.

Any unauthorized access to a computer system might be criminal. If you find some way to access data that you're clearly not supposed to see, it may be a criminal offense. I don't know how much weight it has whether the software provider has been negligent themselves, I assume it depends on the jurisdiction.

I went looking for any recent cases, here's one example[0] of a software provider being negligent, yet the security researcher got the axe:

> In the appeal proceedings on Monday, Aachen Regional Court adopted the assessment of Jülich District Court that access to the secured database constituted a criminal offense. Trial observers from the Chaos Computer Club reported that the court did not care how the defendant had obtained the password. The password was not easy to guess or publicly known, making access a criminal offense.

When I did some hacking myself ~15 years ago, I looked at these kinds of cases and learned to not touch any system that doesn't have a bounty program. Otherwise you put yourself at a lot of risk. Bug bounty programs prohibit access to sensitive data - so if you were to download data like it was done in the article, you might not only not be compensated, but also the company may decide to report you. No company wants to deal with leaked sensitive data, it's a huge business risk for them, so they may take more drastic measures in these cases.

It's pretty much never worth it to download any sensitive data, ever, if you're not a blackhat. In this case, it feels like the security researcher did it for their personal gain to have a more news-worthy report, which in my view puts them in the blackhat category. But that's just my view.

[0]: https://www.heise.de/en/news/Modern-Solution-Court-of-Appeal...

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.

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.

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

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

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!

According to Lovable, more than 50 million projects have been created using its platform.

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.

I think part of it is because they often just the default answer the LLMS spit out when making these projects.

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

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.

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

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.

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